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.
Fixes a bug in cb9b9ea7 where a compatibility typealias for a type
that's been import-as-member'd can't resolve the member, because we're
already in the middle of importing members of the enclosing type.
No tests at the moment because I want to get this in quickly, but also
because the real issue is still there: this should import
successfully.
rdar://problem/31921746
The underlying type's ordering may not be appropriate for the wrapped
type (think an ordered list whose underlying type is NSString).
Frameworks can always add a Comparable conformance explicitly.
We squeak out of this being a source-breaking change by virtue of
never having released a working version of it. Rintaro fixed the
ambiguity problems back in f11b74176b, but that was after the last
rebranch for Swift 3.1.
rdar://problem/30166538
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
(which can happen if an imported class has un-importable initializers)
Our initializer model guarantees that it's safe to inherit convenience
initializers when a subclass has implemented all designated
initializers, since each convenience initializer will be implemented
by calling one of the designated initializers. If one of the
designated initializers /can't/ be implemented in Swift, however,
then inheriting the convenience initializer would not be safe.
This is potentially a source-breaking change, so the importer will
only actually record that it failed to import something in when
compiling in Swift 4 mode.
rdar://problem/31563662
Enums with the ns_error_domain attribute represent codes for NSError,
which means Swift developers will expect to interact with them in
terms of Error. SE-0112 improved bridging for these enums to generate
a struct with the following form:
struct MyError: Error {
@objc enum Code: RawRepresentable {
case outOfMemory
case fileNotFound
}
var userInfo: [NSObject: AnyObject] { get }
static var outOfMemory: Code { get }
static var fileNotFound: Code { get }
}
where MyError.Code corresponds to the original MyError enum defined in
Objective-C. Until recently, both the enum and the synthesized struct
were marked as having the original enum as their "Clang node", but
that leads to problems: the struct isn't really ObjC-compatible, and
the two decls have the same USR. (The latter had already been worked
around.)
This commit changes the struct to be merely considered a synthesized
"external definition", with no associated Clang node. This meant
auditing everywhere that's looking for a Clang node and seeing which
ones applied to external definitions in general.
There is one regression in quality here: the generated struct is no
longer printed as part of the Swift interface for a header file, since
it's not actually a decl with a corresponding Clang node. The previous
change to AST printing mitigates this a little by at least indicating
that the enum has become a nested "Code" type.
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
