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.
The next commits will need access from ModuleFile.cpp.
Also stop pretending we care what kind of error we got back, or that
we might get back random other errors that weren't accounted
for. That's good for crash logs, but not actually interesting here.
(Nearly every place that previously looked for OverrideError will
also accept the upcoming TypeError.)
No effective functionality change.
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.
Module files store all of the Objective-C method entrypoints in a
central table indexed by selector, then filter the results based on
the specific class being requested. Rather than storing the class as
a TypeID---which requires a bunch of deserialization---store its
mangled name. This allows us to deserialize less, and causes circular
deserialization in rdar://problem/31615640.
Add a 'hasExplicitAnyObject()' bit to ProtocolCompositionType
to represent canonical composition types containing '& AnyObject'.
Serialize this bit and take it into account when building
ExistentialLayouts.
Rename ProtocolCompositionType::getProtocols() to getMembers()
since it can contain classes now, and update a few usages that
need further attention with FIXMEs or asserts.
For now, nothing actually constructs these types, and they will
trigger arounds asserts. Upcoming patches will introduce support
for this.
This is a step further from gracefully handling structural changes
to the module format, but we're nowhere near that anyway. At least
avoid the silly mistakes.
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.
Protocols can't have methods marked 'override'. Class contexts should
always be fine to drop a method that's an override (once the rest of
the world can handle it).
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.
All of this information is recoverable from the more-general,
more-sane signature conformances, so stop
recording/serializing/deserializing all of this extra stuff.
This generalizes a hack where re-abstraction thunks become fragile on contact
with fragile functions.
The old policy was:
- [fragile] functions always serialized
- [reabstraction_thunk] transitively referenced from fragile always serialized
The new policy is:
- [serialized] functions always serialized
- [serializable] functions transitively referenced from serialized functions
are always serialized
- Most kinds of thunks can now be [serializable], allowing them to be shared
between serialized and non-serialized code without any issues, as long as the
body of the thunk is sufficiently "simple" (doesn't reference private
symbols or performs direct access to resilient types)
Also, add a third [serializable] state for functions whose bodies we
*can* serialize, but only do so if they're referenced from another
serialized function.
This will be used for bodies synthesized for imported definitions,
such as init(rawValue:), etc, and various thunks, but for now this
change is NFC.
Follow Clang's lead in defining /System/Library/Frameworks and
/Library/Frameworks as default framework search paths. I'm doing this
manually rather than adding them to the actual list of search paths
because Clang will /also/ do this by default, and I don't want to
needlessly duplicate that work.
rdar://problem/31126655
It turned out that a significant part of a swiftmodule’s size is contributed by function declarations and types used by them. Therefore it is important to avoid emitting any functions or function declarations that are not needed by the module.
This change introduces the following changes:
- Function declarations should be serialized only if they are referenced by something that is serialized.
- Function bodies of functions with external linkage should never be serialized.
The only exception are shared_external functions. THis is a workaround, which will be removed in the future (see explanations in SILSerializer::writeSILFunction)
The result of the later change is that functions with external linkage are not put on the SIL serialization worklist and their bodies are not scanned, thus we do not detect references to the functions which are only referenced by functions with external linkage. In particular, the bodies of shared_external functions won’t be serialized at all if they are referenced only from functions with external linkage. And declarations of external functions referenced only from functions with external linkage won’t be serialized too.
With this changes SILSerializer emits significantly fewer function declarations.
Fixes rdar://30081040
