Stop filtering outer overload choices while trying to pre-check
expression, instead have it always fetch those and use new
fix to only attempt them in diagnostic mode (unless it's min/max
situation with conditional conformances).
We don't use this feature anymore (see 0149129ed), and now that we've
branched Swift 5.0 for the last time it's time to rip it out of swiftc
(and then from Clang).
No functionality change, unless someone was compiling their own API
notes. If you were doing that, just copy them into place as text.
Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
Replace `#import` with `#include` as `#import` is a Microsoft type
library inclusion feature on Windows. This enables additional APINotes
tests to pass on Windows.
For the most part, this moves 3/4 tests to 4/5 tests. There are
some interesting changes here because API notes for 4 also apply
to 3 unless otherwise specified, and 4.2 is the next version after
4 rather than 5, but everything should still be correct and testing
useful stuff.
If the Clang declrations are *types*, canonical declaration in Swift is
imported for newest version of Swift. In interface generation, if the
declaration is versioned and it's imported as a member in either or both
version of Swift, we have to take compatibility typealias into account.
* Fixed 'ClangModuleUnit::getTopLevelDecls' to take isCompatibilityAlias() into account
* Fixed bugs in ClangImporter where member-to-member versioned types aren't properly imported.
* Fixed 'SwiftDeclConverter::importFullName' to check equality of getEffectiveContext()
* Fixed 'importer::addEntryToLookupTable' to check equality of getEffectiveContext()
(moved 'ClangImporter::Implementation::forEachDistinctName' to 'NameImporter')
In APINotes, when an unversioned name overrides
a previously declared name with a Swift version, if the
previously declared name is guarded under version 4
the obsoleted version should be 4.2, not 5. In all other
cases, the obsoleted version is the next major Swift
version.
Fixes rdar://problem/39950937
This fixes two easy cases where we would go exponential in type
checking tuple literals.
Instead of generating a conversion to a single type variable (which
results in one large constraint system), we generate a conversion ot
the same type that appears in the initializer expression (which for
tuples is a tuple type, which naturally splits the constraint system).
I experimented with trying to generalize this further, but ran into
problems getting it working, so for now this will have to do.
Fixes rdar://problem/20233198.
ClangImporter::lookupTypeDecl allows a Clang type declaration to be
imported by Clang name instead of by Swift name. Now that we're using
Clang names in mangled names, that's exactly what we need to
reconstruct an AST type from a mangled name.
Also:
- Handle @compatibility_alias in ClangImporter::lookupTypeDecl
- Print errors when type reconstruction fails in swift-ide-test
- Add an extra test for RemoteAST
This makes them consistent no matter what shenanigans are pulled by
the importer, particularly NS_ENUM vs. NS_OPTIONS and NS_SWIFT_NAME.
The 'NSErrorDomain' API note /nearly/ works with this, but the
synthesized error struct is still mangled as a Swift declaration,
which means it's not rename-stable. See follow-up commits.
The main place where this still falls down is NS_STRING_ENUM: when
this is applied, a typedef is imported as a unique struct, but without
it it's just a typealias for the underlying type. There's also still a
problem with synthesized conformances, which have a module mangled
into the witness table symbol even though that symbol is linkonce_odr.
rdar://problem/31616162
"...finally."
This was technically enabled two commits ago, since nothing checks
that you're not /over/ maxVersion(). This is only used for
- deciding the canonical way to import renamed types
- trying to import things in multiple ways
...and so there are very few observable differences, especially
before anyone has added any API notes that differentiate Swift 4
and Swift 5.
At some point we should start encoding name versions in the lookup
tables so that we only have to try all the names /once/, but the test
suite doesn't seem to get measureably slower with this change,
probably because it's pretty quick to decide that most things don't
have multiple names. So we can put that off until later.
*** Depends on Clang change "[APINotes] Record what version caused ***
*** an annotation to get replaced." Update your Clang checkout! ***
More generally, change the meaning of the SwiftVersions section in API
notes to be "this version or earlier" rather than "exactly this
version". We mostly get this behavior for free from the Clang-side
changes, but for SwiftName and the enum annotations we look at inactive
attributes as well. The latter is simple, but the former means being
careful about finding the annotation we /would/ have picked, i.e. the
one closest to the version we requested.
...because they make things harder for people trying to use
Swift.print. Before:
error: 'print' has been renamed to 'printDocument(_:)'
After:
error: use of 'print' nearly matches global function
'print(_:separator:terminator:)' in module 'Swift'
rather than instance method 'print(_:extra:)'
(This actually occurs with AppKit's NSDocument, so it's not just a
hypothetical concern.)
rdar://problem/32839733
The behavior in versioned-objc.swift changes now that we've fixed
this, since we always prefer to use a type's Swift 4 name. A handful
of new tests have also been added to versioned.swift.
Also lays the groundwork for rdar://problem/16513537, which is about
being able to find an enum by its original top-level name so that we
can show a diagnostic for that. I'll file a public bug about that
later.
rdar://problem/31893305
When "Always import types under their Swift 4 name." was
introduced, we still import members under their Swift 3 names;
this means the member's DeclContext imports as a compatibility
alias.
However, we did not look through the compatibility alias when
mapping the member's Clang DeclContext to a Swift DeclContext,
and as a result, the member was dropped on the floor.
Fixes <rdar://problem/31911531>, <rdar://problem/32042522>,
and probably <rdar://problem/31976966>.
When a swift_wrapper'd type is renamed from Swift 3 -> 4, we create a
typealias for it. We need to look through that typealias when
deserializing members of that type, e.g., global variables of the
swift_wrapper'd type.
This reverts commit 25985cb764. For now,
we're trying to avoid spurious non-structural changes to the mangling,
so that the /old/ mangling doesn't appear to change. That doesn't mean
no changes at all, but we can save this one for later.
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
When a type is renamed, we leave behind a "compatibility typealias"
whose underlying type uses the new name. For generic types, though, we
were using the generic parameters and environment of the original
type, which is completely bogus. "Fix" this by just dropping the
generic part entirely and making a typealias that refers to the
/unbound/ generic type, as if written as `typealias OldName = NewName`
instead of `typealias OldName<Element> = NewName<Element>`. The rest
of the compiler can handle that fine.
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
Generic Objective-C classes with this annotation will be imported as
non-generic in Swift. The Swift 3 behavior hardcoded a certain set of
class /hierarchies/ as permanently non-generic, and this is preserved
in Swift 3 mode.
Actually using this API note in a versioned way (as opposed to just
marking the class non-generic in all language versions) will cause
horrible source compatibility problems in the mix-and-match cases,
where Swift 3 code presents a non-generic type that Swift 4 expects to
be generic or vice versa. Fixes for this will come later; right now
it's more important to add support for the feature at all.
To avoid unwanted changes in Swift 4, this commit also adds API notes
to make any existing classes in the previously-hardcoded set continue
to import as non-generic even in Swift 4. The difference is that
/subclasses/ of these classes may come in as generic. (If we want to
make a change here, that can be a separate commit.)
rdar://problem/31226414 (Swift side of rdar://problem/28455962)
