For the Optional<Module *> returned by getClangSubmoduleForDecl, the
outside Optional specifies whether there's an answer at all. That
answer can still be null if the declaration comes from a bridging
header. In this particular case, we're guaranteed to get an answer,
but that answer may be null.
rdar://problem/32463543
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
This changes `getBaseName()` on `DeclName` to return a `DeclBaseName`
instead of an `Identifier`. All places that will continue to be
expecting an `Identifier` are changed to call `getBaseIdentifier` which
will later assert that the `DeclName` is actually backed by an
identifier and not a special name.
For transitional purposes, a conversion operator from `DeclBaseName` to
`Identifier` has been added that will be removed again once migration
to DeclBaseName has been completed in other parts of the compiler.
Unify approach to printing declaration names
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Previously this (1) did not work (the constant just disappeared), and
(2) would actually crash if the destination context was a class.
rdar://problem/32208235
The GenericSignatureBuilder requires `finalize()` to be called before a
generic signature can be retrieved with `getGenericSignature()`. Most of the former isn’t strictly needed unless you want a generic signature, and the
latter is potentially expensive. `computeGenericSignature()` combines the two
operations together, since they are conceptually related. Update most of the
callers to the former two functions to use `computeGenericSignature()`.
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>.
Like NSObject, CFType has primitive operations CFEqual and CFHash,
so Swift should allow those types to show up in Hashable positions
(like dictionaries). The most general way to do this was to
introduce a new protocol, _CFObject, and then have the importer
automatically make all CF types conform to it.
This did require one additional change: the == implementation that
calls through to CFEqual is in a new CoreFoundation overlay, but the
conformance is in the underlying Clang module. Therefore, operator
lookup for conformances has been changed to look in the overlay for
an imported declaration (if there is one).
This re-applies 361ab62454, reverted in
f50b1e73dc, after a /very/ long interval
where we decided if it was worth breaking people who've added these
conformances on their own. Since the workaround isn't too difficult---
use `#if swift(>=3.2)` to guard the extension introducing the
conformance---it was deemed acceptable.
https://bugs.swift.org/browse/SR-2388
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.
