That is, whether an initializer is 'required', and either does not
override anything or overrides a non-required initializer. We don't
use this for anything now, but it'll show up in the next commit.
Till now createApply, createTryApply, createPartialApply were taking some arguments like SubstCalleeType or ResultType. But these arguments are redundant and can be easily derived from other arguments of these functions. There is no need to put the burden of their computation on the clients of these APIs.
The removal of these redundant parameters simplifies the APIs and reduces the possibility of providing mismatched types by clients, which often happened in the past.
Deserializing a witness record in a conformance may fail if either of the requirement or witness changed name or type, most likely due to SDK modernization changes across Swift versions. When this happens, leave an opaque placeholder in the conformance to indicate that the witness exists but we don't get to see it. For expedience, right now this just witnesses the requirement to itself, so that code in the type checker or elsewhere that tries to ad-hoc devirtualize references to the requirement just gets the requirement back. Arguably, we shouldn't include the witness at all in imported conformances, since they should be an implementation detail, but that's a bigger, riskier change. This patch as is should be enough to address rdar://problem/31185053.
All we need to store is whether the SILDeclRef directly
references the declaration, or if it references a curry
thunk, and we already have an isCurried bit for that.
Replace `NameOfType foo = dyn_cast<NameOfType>(bar)` with DRY version `auto foo = dyn_cast<NameOfType>(bar)`.
The DRY auto version is by far the dominant form already used in the repo, so this PR merely brings the exceptional cases (redundant repetition form) in line with the dominant form (auto form).
See the [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es11-use-auto-to-avoid-redundant-repetition-of-type-names) for a general discussion on why to use `auto` to avoid redundant repetition of type names.
This lets us serialize that decision, which means we can conceivably
/change/ the decision in later versions of the compiler without
breaking existing code. More immediately, it's groundwork that will
eventually allow us to drop decls from the AST without affecting
vtable layout.
This isn't actually a great answer; what we really want is for SIL
vtables to be serialized consistently and treated as the point of
truth. But that would be more change than we're comfortable taking in
the Swift 4 timeframe.
First part of rdar://problem/31878396.
This attribute allows one to provide the "legacy" name of a class for
the purposes of archival (via NSCoding). At the moment, it is only
useful for suppressing the warnings/errors about classes with unstable
archiving names.
A cross-reference in a module cannot refer to a parsed entity, because the parsed entity couldn’t have been seen when the module was built. Filter these out, which prevents a crash in the subsequent commit.
Finishes up the "big four" non-type decl kinds. Unfortunately,
indiscriminately dropping members from a class affects the layout
of its vtable. That issue is tracked by rdar://problem/31878396.
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.
