All of this information is recoverable from the more-general,
more-sane signature conformances, so stop
recording/serializing/deserializing all of this extra stuff.
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
There are Apple-internal buildbots that test without the compiler API
notes present, so 08b6c5f wasn't good enough. For now, keep inferring
that subclasses of NSArray et al /within Foundation/ should be
imported as non-generic even in Swift 4 mode.
rdar://problem/31418165
Reverts PR #8468 to re-add an assertion I had temporarily removed.
I think we can actually enforce this condition now.
This reverts commit 131513e31f, reversing
changes made to ae6268155a.
Avoids yet another circular import issue: conformance on type X ->
associated types -> members -> members of superclass type (for naming
conflicts) -> SwiftWrapper type -> conformances on underlying type X.
Normally this circularity is fine, but I still want to put back the
assertion I reverted in 19a2ad5f17.
I unfortunately don't have a test for the actual failure here; it came
up on some Apple-internal code and heavily depended on both Foundation
and the standard library. I did confirm that this fixes it, and it
looks like it does so without causing any issues for swift_wrapper
types.
More rdar://problem/30785976
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)
We can still get into circular import cases that result in us trying
to import the members of a category before we've finished with the
members of the original class. I need to fix that, but for now disable
the assertion to unblock some Apple-internal bots.
rdar://problem/31374687
Previously we were checking if a declaration was a redeclaration by
looking at the contextual type, but it should be looking at the
interface type in order to handle categories of classes using
Objective-C lightweight generics.
This also fixes a mistaken reuse of 'containerTy' after I changed its
meaning in the last commit. Doug's review comment was right: it /is/
bad to use an existing name for a new purpose!
More rdar://problem/30785976.
This ensures that any @property redeclarations that appear in class
extensions (a special kind of category in ObjC) do not affect the
primary type of the property as declared in the class itself.
To accomplish this, lookups in importDecl that are checking for
conflicts now no longer pull in new categories/extensions if the
current context is a ClassDecl.
rdar://problem/30785976
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.
If a top-level declaration is imported as a member in Swift 4 but not
in Swift 3, it would still show up in the lookup table for the
containing type in Swift 3 mode. We would import it, and then try to
add the top-level declaration to the containing type.
I'm about to redo this anyway so that the versioned stub will show up
(the one for the Swift 4 name) but this is the narrow fix that avoids
the assertion failure we were seeing.
rdar://problem/31161489
If this had a default, it should be the effective language version,
not the compiler language version. That is, in the Swift 4 compiler's
Swift 3 mode, we want to be acting like Swift 3, not Swift 4.
New GenericTypeParamDecls should always be created with an
InvalidDepth, to prevent canonicalization before the generic
parameter list has been type checked.
The protocol conformance checker verifies that all of the requirements
in the protocol's requirement signature are fulfilled. Save the
conformances from that check into the NormalProtocolConformance,
because this is the record of how that concrete type satisfies the
protocol requirements.
Compute, deserialize, and verify this information, but don't use it
for anything just yet. We'll use this to eliminate the "inherited
protocol map" and possibility some redundant type-witness
information.
Previously some decls (TypeAliasDecl and ExtensionDecl) had bits
explicitly marking whether they've been validated, while other decls
just deduced this from hasInterfaceType. The doing the latter doesn't
work when the interface type can be computed before doing full
validation (such as protocols and associatedtypes, which have trivial
interface types), and so an explicit bit is adopted for all decls.
The compiler itself no longer uses this API but the debugger does,
in order to pretty-print option sets.
The normal way to test this would be to add an LLDB-side test that
uses a framework with versioned API notes. Unfortunately I can't
think of a straightforward way to test it Swift-side.
Unlike values, we can't import multiple copies of types under
different names and get good results. Instead, we make a typealias
that points back to the original type. Make sure this typealias is
flagged with whatever version is appropriate, rather than always using
"Swift 2".
When a C declaration is marked unavailable with a replacement, we look
for the replacement to see how it would be imported into Swift. Make
sure we do that with respect to the active language version.
This doesn't actually have any effect yet, but if we start importing
both Swift 3 and Swift 4 versions of protocol requirements and the
non-active one is unavailable, we might mistakenly mark the protocol
un-implementable even when the requirements that are needed are all
there. (Hopefully we would never make a protocol /less/ available in a
newer release, of course.) The test case is designed to catch that.
...and Swift 4 versions in Swift 3, and Swift 2 and "raw" versions in
both. This allows the compiler to produce sensible errors and fix-its
when someone uses the "wrong" name for an API. The diagnostics
certainly have room to improve, but at least the essentials are there.
Note that this commit only addresses /top-level/ decls, i.e. those
found by lookup into a module. We're still limited to producing all
members of a nominal type up front, so that'll require a slightly
different approach.
Part of rdar://problem/29170671
