* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
This means all cross-module references and all mangled names will
consistently use the Swift 4 name (the canonical type), no special
handling required.
The main thing we lose here is that the Swift 4 names of imported
types become usable in Swift 3 mode without any diagnostics, similar
to how most language features introduced in Swift 4 are available in
Swift 3 mode. It also implies that the Swift 4 name will show up in
demangled names.
rdar://problem/31616162
Introduce a warning about redeclaring the associated types from an
inherited protocol in the protocol being checked:
* If the new declaration is an associated type, note that the
declaration could be replaced by requirements in the protocol's
where clause.
* If the new declaration is a typealias, note that it could be
replaced by a same-type constraint in the protocol's where clause.
These tests included sources that are
based on Swift 3. They can be considered to be updated later to Swift 4, but it did not seem critical for what they were testing.
These new Clang attributes identify whether an enum is intended to
represent an option set or not, and whether the set of cases listed in
the enum declaration is exhaustive. (Swift doesn't currently have a
closed/open distinction for enums, so treat any C enum with
enum_extensibility as a proper closed Swift enum, like we do with
NS_ENUM.)
Enums with neither attribute will continue to be imported as unique
types.
rdar://problem/28476618
- Allow them to use substitutions.
- Consistently use 'a' as a mangling operator.
- For generic typealiases, include the alias as context for any generic
parameters.
Typealiases don't show up in symbol names, which always refer to
canonical types, but they are mangled for debug info and for USRs
(unique identifiers used by SourceKit), so it's good to get this
right.
Rather than requiring associated type witness inference to go and
figure out the _ObjectiveCType type from the other witnesses for imported
swift_wrapper/swift_newtype'd types, synthesize the typealias directly in the
importer. This is a simplification and a performance optimization.
Rather than requiring associated type witness inference to go and
figure out the Element type from the other witnesses for imported
OptionSet types, synthesize the typealias directly in the
importer. This is a simplification and a performance optimization.
Rather than requiring associated type witness inference to go and
figure out the RawValue type from the rawValue witnesses for imported,
RawRepresentable types, synthesize the typealias directly in the
importer. This is a simplification and a performance optimization.
- Add CompilerInvocation::getPCHHash
This will be used when creating a unique filename for a persistent
precompiled bridging header.
- Automatically generate and use a precompiled briding header
When we're given both -import-objc-header and -pch-output-dir
arguments, we will try to:
- Validate what we think the PCH filename should be for the bridging
header, based on the Swift PCH hash and the clang module hash.
- If we're successful, we'll just use it.
- If it's out of date or something else is wrong, we'll try to
emit it.
- This gives us a single filename which we can `stat` to check for the
validity of our code completion cache, which is keyed off of module
name, module filename, and module file age.
- Cache code completion results from imported modules
If we just have a single .PCH file imported, we can use that file as
part of the key used to cache declarations in a module. Because
multiple files can contribute to the __ObjC module, we've always given
it the phony filename "<imports>", which never exists, so `stat`-ing it
always fails and we never cache declarations in it.
This is extremely problematic for projects with huge bridging headers.
In the case where we have a single PCH import, this can bring warm code
completion times down to about 500ms from over 2-3s, so it can provide a
nice performance win for IDEs.
- Add a new test that performs two code-completion requests with a bridging header.
- Add some -pch-output-dir flags to existing SourceKit tests that import a bridging
header.
rdar://problem/31198982
That is, the stubs we generate when you rename a C global function
imported as a type member using the SwiftName API note. (See the
test case changes.) Previously we hit an assertion.
For good measure, also fix versioned stubs for types-as-members,
which were always added to their original context rather than the
new context.
rdar://problem/31435658
Substitution into a generic function type produces non-canonical
generic signatures. This functionality should either be removed or be
completely rewritten to properly use the GenericSignatureBuilder. For
now, disable this one client's unsafe use of it.
This does regression code-completion results slightly, where we were
depending on OverrideFilteringConsumer's behavior to filter out some
redundant results. I've captured the work to fix this properly in
rdar://problem/31245556.
A more general solution to ae458a84ad: import all versions of a name
that are going to show up as members, ignore those that aren't.
Further work on <rdar://problem/29170671> Import APIs under their
Swift 3 names.
