Ever since we stopped associating the top-level struct of an imported
NS_ERROR_ENUM with the Clang enum declaration, we've been unable to
print imported NS_ERROR_ENUMs. The module-printing infrastructure
would drop them thinking they aren't imported declarations.
This also affected NS_ERROR_ENUMs that were imported as members of
another type, as well as other types imported as members.
Fixes rdar://problem/32497693.
That is, if a member is redeclarable, use the module of the definition
if possible, and the canonical declaration otherwise. This is
consistent with what we do when we actually import the declaration.
Without this, we can end up dropping declarations.
rdar://problem/32816381
In Swift 3 mode, infer @_downgrade_exhaustivity_check for any enum
elements that were introduced in the 2017 SDKs (macOS 10.13, iOS 11.0,
tvOS 11.0, watchOS 4.0). This is a stop-gap until we get "open" enums,
but serves an important source-compatibility use case.
Fixes rdar://problem/32824207.
`ClangImporter`'s `importType` should always return interface types
for everything it imports, which helps to avoid tracking of declaration
contexts and remapping returned types in/out of them.
Resolves: rdar://problem/32298667
Previously, we did not properly handle levels of indirection for
swift_newtype-ed typedefs of pointer types. We imported them in a way
that tried to present the value semantics of the pointee rather than
of the pointer. We then tried (sometimes incorrectly) to detect and
fix this up during SILGen.
Instead, model with the value semantics of the pointer itself. SILGen
can then be simplified to just pass swift_newtypes the same as any
other struct: directly for non-mutating and indirectly for mutating
(i.e. inout self). Tests added.
Method types are now required to be `(Self) -> (Args...) -> Return`, not
`Self -> (Args...) -> Return`.
See also https://github.com/apple/swift/pull/9454 .
Fixes rdar://problem/32588152 .
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.
