We already ban all structs from declaring storage that comes from implementation-only imports. Until now we missed property wrappers, they were just dropped in deserialization.
Resolves rdar://problem/59403617
Components of a requirement may be hidden behind an implementation-only
import. Attempts at deserializing them would fail on a 'module not
loaded' error. We only see failures in non-compilation paths, either in
indexing or with tools like ide-test as they try to deserialize
things that are private.
* [TypeChecker] Enclosing stubs protocol note within editor mode
* [test] Removing note from test where there is no -diagnostics-editor-mode flag
* Formatting modified code
* [tests] Fixing tests under validation-tests
In some circumstances, a Swift declaration in module A will depend on
another declaration (usually from Objective-C) that can't be loaded,
for whatever reason. If the Swift declaration is *overriding* the
missing declaration, this can present a problem, because the way
methods are dispatched in Swift can depend on knowing the original
class that introduced the method. However, if the compiler can prove
that the override can still be safely invoked/used in all cases, it
doesn't need to worry about the overridden declaration being missing.
This is especially relevant for property accessors, because there's
currently no logic to recover from a property being successfully
deserialized and then finding out that an accessor couldn't be.
The decision of whether or not an override can be safely invoked
without knowledge of the base method is something to be cautious
about---a mistaken analysis would effectively be a miscompile. So up
until now, this was limited to one case: when a method is known to be
`@objc dynamic`, i.e. always dispatched through objc_msgSend. (Even
this may become questionable if we have first-class method references,
like we do for key paths.) This worked particularly well because the
compiler infers 'dynamic' for any overload of an imported Objective-C
method or accessor, in case it imports differently in a different
-swift-version and a client ends up subclassing it.
However...that inference does not apply if the class is final, because
then there are no subclasses to worry about.
This commit changes the test to be more careful: if the /missing/
declaration was `@objc dynamic`, we know that it can't affect ABI,
because either the override is properly `@objc dynamic` as well, or
the override has introduced its own calling ABI (in practice, a direct
call for final methods) that doesn't depend on the superclass. Again,
this isn't 100% correct in the presence of first-class methods, but it
does fix the issue in practice where a property accessor in a parent
class goes missing. And since Objective-C allows adding property
setters separately from the original property declaration, that's
something that can happen even under normal circumstances. Sadly.
This approach could probably be extended to constructors as well. I'm
a little more cautious about throwing vars and subscripts into the mix
because of the presence of key paths, which do allow identity-based
comparison of overrides and bases.
rdar://problem/56388950
Harden more of the serialization functions to propagate errors for
the caller to handle these errors gracefully. This fixes a crash in
finishNormalConformance when indexing a system module with an
implementation-only import.
rdar://problem/52837313
Accessors logically belong to their storage and can be synthesized
on the fly, so removing them from the members list eliminates one
source of mutability (but doesn't eliminate it; there are also
witnesses for derived conformances, and implicit constructors).
Since a few ASTWalker implementations break in non-trivial ways when
the traversal is changed to visit accessors as children of the storage
rather than peers, I hacked up the ASTWalker to optionally preserve
the old traversal order for now. This is ugly and needs to be cleaned up,
but I want to avoid breaking _too_ much with this commit.
Once accessors are no longer listed as members of their parent context,
a failure to deserialize a VarDecl or SubscriptDecl needs to create a
MissingMemberDecl with the total number of vtable entries expected for
all of the accessors of the storage.
Note that until the accessor change actually lands, we always compute
the expected number of vtable entries as 0.
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
If a protocol inherits from a protocol that can't be loaded, drop it
entirely. Similarly, if it has requirements that reference types in
other modules that can't be loaded, drop the protocol entirely---at
least for now, we don't want to deal with a protocol that exists but
has the wrong requirement signature. That "in other modules" isn't
perfect, but it avoids cases where two protocols depend on each other.
Unfortunately, it means the compiler may still get into exactly the
situation above if a protocol depends on another protocol in the same
module, and /that/ protocol can't be loaded for some other reason. But
it's progress.
This comes up when referencing implementation-only-imported protocols
from non-public protocols, but is also just general deserialization
recovery goodness.
rdar://problem/52141347
...specifically `@objc dynamic`, that is. This is one case where we
/know/ that the override does not depend on the base in any way---any
attributes have already been propagated down, and there's no vtable
entry. This is especially important for properties, which have no
recovery if their accessors can't be deserialized.
rdar://50827914
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.
