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