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.)
As such, we no longer insert two placeholders for initializers that
need two vtable slots; instead we record that in the
MissingMemberDecl. I can see MissingMemberDecl growing to be something
we'd actually show to users, that can be used for other kinds of
declarations that don't have vtable entries, but for now I'm not going
to worry about any of that.
If a base method's not available, we already drop the overridding
method. Make sure this works even when the base method is itself
an override that failed to load.
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.
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.
