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.
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.
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.
