That is, if a struct's generic requirements can't be deserialized,
drop the struct. This is the same logic that's already in play for
enums and (as of the previous commit) classes, so it should be pretty
well tested by now. (Hence the sole test I'm adding here, snuck into
superclass.swift because it's a superclass /constraint/ being tested.)
I don't know of any outstanding issues caused by this, but it was
weird to have it for enums and classes but not structs, so here we
are.
...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
We want to be able to define classes with a fixed storage layout,
but a resilient (opaque) vtable. If the class is also generic,
we still have to load field offsets from the metadata if they
are dependent.
So put the field offsets after the generic arguments and before
the vtable.
This is an ABI break for @_fixed_layout classes, which are
defined by the stdlib.
The recovery logic was erronously kicking in, because it was comparing
the substituted underlying type with the declaration's underlying type.
For a generic typealias, these never equal, so instead, serialize the
unsubstituted type, and substitute it in deserialization.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
If, for whatever reason, a type used in an extension's generic
requirements is missing, just drop the whole extension. This isn't
wonderful recovery, but in practice nothing should be able to use the
extension anyway, since the relevant type in question is missing.
...Okay, that's not quite true; there could, for example, be inlinable
code that references one of these methods. However, that (1) isn't
worse than the behavior for any other inlinable code (which doesn't
yet attempt to recover from missing declarations), and (2) is still a
strict improvement over the current situation, where we will eagerly
abort the compiler trying to load the extension in the first place.
rdar://problem/40956460
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
And provide better semantic background by surrounding 'nil' in ticks when it is referred to as a value
Added missing tests for certain cases involving nil capitalization
Extend witness tables with a pointer to the protocol conformance
descriptor from which the witness table was generated. This will allow
us to determine (for example) whether two witness tables were
generated from the same (or equivalent) conformances in the future, as
well as discover more information about the witness table itself.
Fixes rdar://problem/36287959.
Follow-up to ac6fd7214 that adds a similar feature for enums. This
probably doesn't come up much, but the infrastructure's already there.
(The previous commit showed that the other places we do recovery
already handle this from their normal collection of "dependency
types".)
The existing code already handles this, so it's just a matter of
testing what happens for these declarations that can be generic:
functions, initializers, and subscripts. (Enums are coming in the next
commit.) Note that we currently don't try to recover at all for a
struct or class whose generic requirements aren't valid anymore.
We could handle a typealias itself disappearing, but not if the
typealias was okay but the underlying type wasn't. This came up in
real Swift 3/4 mix-and-match code.
rdar://problem/34940079
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.)
This shows up with swift_wrapper typedefs, which get imported into
Swift as structs. If someone makes an extension of a swift_wrapper
type, but the swift_wrapper is only applied in Swift 4 mode, that
extension will break any Swift 3 clients. Recover by just dropping
the extension entirely.
There's still more complexity around extensions---what if a
requirement can't be deserialized? what if something's depending on
the protocol conformance provided by the extension?---but the missing
base type case should be pretty safe. If you can't see the type at
all, things that depend on its conformances are already in trouble.
rdar://problem/33636733
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
Currently some contextual errors are discovered too late
which leads to diagnostics of unrelated problems like argument
mismatches, these changes attempt to improve the situation
and try to diagnose contextual errors related to calls
before everything else.
Resolves: SR-5045, rdar://problem/32934129
Layout for an enum depends very intimately on its cases---both their
existence and what their payload types are. That means there's no way
to "partly" recover from failure to deserialize an individual case's
payload type, the way we can partly recover from failing to
deserialize an initializer in a class. Add deserialization recovery
to enums by validating all of their payload types up front, and
dropping the enum if we can't import all of the cases.
This is the first time where we're trying to do deserialization
recovery for a /type/, and that could have many more ripple effects
than for a var/func/subscript/init. A better answer here might be to
still import the enum but mark it as unavailable, but in that case
we'd have to make sure to propagate that unavailability to anything
that /used/ the enum as well. (In Swift, availability is checked based
on use of the name, so if someone manages to refer to an enum using
inferred types we'd be in trouble.)
There is one case here that's not covered: if an enum case has a
payload that references a type declaration nested within the enum, but
then that nested type /itself/ can't be loaded for some reason, we
have no way to check that up front, because we can't even try to load
the nested type without loading its parent DeclContext (the enum). I
can't think of an easy solution for this right now.
(In the future, we'll be able to support dropping a single case for
resilient enums. But we're not there right now.)
rdar://problem/31920901
This isn't an inherent limitation of the language---in fact, it would
be a problem for library evolution if you had to know a superclass's
full vtable contents to generate the vtable for a subclass. However,
that's exactly where we are today, and that's not going to change for
Swift 4.
One small hole in the Swift 3 / Swift 4 story.
More rdar://problem/31878396
