In the added test case, the `typealias` refers to the `HiddenStruct` type in the private module, which is imported as `@_implementationOnly`. Because the import is `@_implementationOnly`, during deserialization, we don’t import the private module and hence any reference to the `HiddenStruct` type fails. In the common deserialization code path, this causes us to skip over the `typealias` member. However, when creating the protocol conformance, we assume that we can resolve the type to which the `typealias` refers and thus we are crashing.
If `LangOpts.EnableDeserializationRecovery` is set to `true`, we should do our best to recover from such failures so this patch makes the deserialization failure handling more graceful and resolve the right-hand side of the `typealias` as an `ErrorType`.
Fixes rdar://72891807
In some circumstances, a Swift declaration in module A will depend on
another declaration (usually from Objective-C) that can't be loaded,
for whatever reason. If the Swift declaration is *overriding* the
missing declaration, this can present a problem, because the way
methods are dispatched in Swift can depend on knowing the original
class that introduced the method. However, if the compiler can prove
that the override can still be safely invoked/used in all cases, it
doesn't need to worry about the overridden declaration being missing.
This is especially relevant for property accessors, because there's
currently no logic to recover from a property being successfully
deserialized and then finding out that an accessor couldn't be.
The decision of whether or not an override can be safely invoked
without knowledge of the base method is something to be cautious
about---a mistaken analysis would effectively be a miscompile. So up
until now, this was limited to one case: when a method is known to be
`@objc dynamic`, i.e. always dispatched through objc_msgSend. (Even
this may become questionable if we have first-class method references,
like we do for key paths.) This worked particularly well because the
compiler infers 'dynamic' for any overload of an imported Objective-C
method or accessor, in case it imports differently in a different
-swift-version and a client ends up subclassing it.
However...that inference does not apply if the class is final, because
then there are no subclasses to worry about.
This commit changes the test to be more careful: if the /missing/
declaration was `@objc dynamic`, we know that it can't affect ABI,
because either the override is properly `@objc dynamic` as well, or
the override has introduced its own calling ABI (in practice, a direct
call for final methods) that doesn't depend on the superclass. Again,
this isn't 100% correct in the presence of first-class methods, but it
does fix the issue in practice where a property accessor in a parent
class goes missing. And since Objective-C allows adding property
setters separately from the original property declaration, that's
something that can happen even under normal circumstances. Sadly.
This approach could probably be extended to constructors as well. I'm
a little more cautious about throwing vars and subscripts into the mix
because of the presence of key paths, which do allow identity-based
comparison of overrides and bases.
rdar://problem/56388950
Harden more of the serialization functions to propagate errors for
the caller to handle these errors gracefully. This fixes a crash in
finishNormalConformance when indexing a system module with an
implementation-only import.
rdar://problem/52837313
...specifically `@objc dynamic`, that is. This is one case where we
/know/ that the override does not depend on the base in any way---any
attributes have already been propagated down, and there's no vtable
entry. This is especially important for properties, which have no
recovery if their accessors can't be deserialized.
rdar://50827914
...instead of crashing. Also drop the class if its generic
requirements depend on a type that can't be loaded (instead of
crashing).
rdar://problem/50125674
We already detected when a typealias /changed/ incompatibly; being
unable to deserialize it at all is just a very dramatic version of
that, right?
https://bugs.swift.org/browse/SR-9811
llvm::Expected/llvm::Error require that the error is not just checked
but explicitly handled. Since we're currently recovering as if nothing
happened, we need to use llvm::consumeError to throw the error info
away.
rdar://problem/40738521
Now that we use the C names of imported types in mangled names, it's
safe to resolve a compatibility alias when a type gets an
NS_SWIFT_NAME for the first time, rather than requiring the developer
to recompile the imported library.
This doesn't include generic types, which only applies for Objective-C
generics. There shouldn't be additional complications here but I want
to be extra careful.
rdar://problem/39661212
If we can't resolve a cross-reference unambiguously, we're supposed to
produce an llvm::Error and let the calling code handle it. However, if
we couldn't even resolve the /type/ of the cross-reference, we would
just crash. Follow the supported error path in that case too -- in
many cases the error can just propagate upwards to something that can
handle it.
rdar://problem/34821187, plus an extra test case from
rdar://problem/35157494. (The latter will be fixed better later, but
meanwhile let's not regress on the crashing part.)
When there's an Objective-C protocol that adopts other protocols, the
other protocols become part of the requirement signature. If that can
change, Swift conformances to that protocol will get very confused
when it comes time to deserialize the conformances that satisfy the
requirement signature.
To recover from this, just deserialize /all/ trailing conformances,
rather than follow the requirement signature, and match them up after
the fact. (This only works for Objective-C protocols where we know all
conformance requirements represent inherited protocols, as opposed to
constraints on associated types.)
rdar://problem/33356098
If there's an error deserializing part of a type, just propagate it
out. Also add support for bound generic types. This isn't meant to be
full coverage of possible failures, just ones that are likely to come
up through the C/ObjC importer.
Still to do:
- Generic function types (only show up on functions)
- Unbound generic types (only show up on typealiases, which I may not
even tackle)
Proof-of-concept for the above. This shouldn't be common---renames are
far more likely, and those we can track---but occurs when the
swift_wrapper attribute (the implementation of NS_STRING_ENUM) is
active in Swift 4 but not in Swift 3.
Note that this only checks the canonical interface type of the
declaration, because the non-canonical type may contain references to
the declaration's generic parameters.
This keeps us from showing Swift 3 names in Swift 4 code;
unfortunately, as the test case shows, we still have a few cases where
Swift /4/ names will leak into Swift /3/ code. I'm considering this an
acceptable state of events for now.
This is the same as the last few commits, but with the additional
complication of designated initializers affecting other behavior
around the type. In particular, convenience initializers cannot be
invoked on subclasses if the designated initializers are not all
present on the subclass. If a designated initializer is dropped, it's
not possible to satisfy that.
It would be nice to do better here, since a class's initializers are
mostly independent of the superclass's initializers. Unfortunately, it
still affects whether /this/ class can inherit convenience
initializers, as well as vtable layout. This is conservative, at
least.
In order to accomplish this, cross-module references to typealiases
are now banned except from within conformances and NameAliasTypes, the
latter of which records the canonical type to determine if the
typealias has changed. For conformances, we don't have a good way to
check if the typealias has changed without trying to map it into
context, but that's all right---the rest of the compiler can already
fall back to the canonical type.
Like the previous commit, but with added trickiness because we also
serialize the form of the PatternBindingDecl a property came from.
Make getPattern handle a failure in the simple case that overrides
use, and pass that up to the PatternBindingDecl initialization. (This
can result in zero-element PatternBindingDecls, but that's fine.)
'getPattern' is also a change from 'maybeGetPattern', but every caller
knows how many patterns it expects, so accomodating the "maybe" case
is no longer important.
That is, a Swift 3 target imported into a Swift 4 context or vice
versa. This requires serializing the compatibility mode explicitly,
instead of including it in the textual version string that's only
for debugging.
Proof-of-concept for this sort of recovery. In the real world, it's
more likely that this will happen due to differences between Swift 3
and Swift 4, rather than changes in what macros are defined, but the
latter can still happen when debugging.
There's a lot to do here to consider this production-ready. There are
no generics involved and no potential circular references, and the
/rest/ of the compiler isn't prepared for this either. But it's cool
to see it working!
Actually recovering is hidden behind the new
-enable-experimental-deserialization-recovery option; without it the
compiler will continue to eagerly abort.
