Every other declaration kind gets this for free in its interface type,
but properties don't. Just add a bit, it's simple enough.
rdar://problem/30289803
Storing this separately is unnecessary since we already
serialize the enum element's interface type. Also, this
eliminates one of the few remaining cases where we serialize
archetypes during AST serialization.
There's a class of errors in Serialization called "circularity
issues", where declaration A in file A.swift depends on declaration B
in file B.swift, and B also depends on A. In some cases we can manage
to type-check each of these files individually due to the laziness of
'validateDecl', but then fail to merge the "partial modules" generated
from A.swift and B.swift to form a single swiftmodule for the library
(because deserialization is a little less lazy for some things). A
common case of this is when at least one of the declarations is
nested, in which case a lookup to find that declaration needs to load
all the members of the parent type. This gets even worse when the
nested type is defined in an extension.
This commit sidesteps that issue specifically for nested types by
creating a top-level, per-file table of nested types in the "partial
modules". When a type is in the same module, we can then look it up
/without/ importing all other members of the parent type.
The long-term solution is to allow accessing any members of a type
without having to load them all, something we should support not just
for module-merging while building a single target but when reading
from imported modules as well. This should improve both compile time
and memory usage, though I'm not sure to what extent. (Unfortunately,
too many things still depend on the whole members list being loaded.)
Because this is a new code path, I put in a switch to turn it off:
frontend flag -disable-serialization-nested-type-lookup-table
https://bugs.swift.org/browse/SR-3707 (and possibly others)
Most of this involved sprinkling ValueOwnershipKind::Owned in many places. In
some of these places, I am sure I was too cavalier and I expect some of them to
be trivial. The verifier will help me to track those down.
On the other hand, I do expect there to be some places where we are willing to
accept guaranteed+trivial or owned+trivial. In those cases, I am going to
provide an aggregate ValueOwnershipKind that will then tell SILArgument that it
should disambiguate using the type. This will eliminate the ackwardness from
such code.
I am going to use a verifier to fix such cases.
This commit also begins the serialization of ValueOwnershipKind of arguments,
but does not implement parsing of value ownership kinds. That and undef are the
last places that we still use ValueOwnershipKind::Any.
rdar://29791263
This is dead code and can be re-added if it is needed. Right now though there
really isnt a ValueOwnershipKind that corresponds to deallocating and I do not
want to add a new ValueOwnershipKind for dead code.
The typedef `swift::Module` was a temporary solution that allowed
`swift::Module` to be renamed to `swift::ModuleDecl` without requiring
every single callsite to be modified.
Modify all the callsites, and get rid of the typedef.
For this we need to store the linkage of the “original” method implementation in the vtable.
Otherwise DeadFunctionElimination thinks that the method implementation is not public but private (which is the linkage of the thunk).
The big part of this change is to extend SILVTable to store the linkage (+ serialization, printing, etc.).
fixes rdar://problem/29841635
Teach the serialized form of ArchetypeType about its owning generic
environment, so we can wire up the generic environment of (primary)
archetypes eagerly (at the point of deserialization) rather than when
we form the generic environment. This ensures that there is no point
at which we have a (non-opened-existential) archetype without a
generic environment.
... except that the type reconstruction code creates such archetypes.
Teach the serialization of SIL generic environments, which used to be
a trailing record following the SIL function definition, to use the
same uniqued "generic environment IDs" that are used for the AST
generic environments. Many of them overlap anyway, and SIL functions
tend to have AST generic environments anyway.
This approach guarantees that the AST + SIL deserialization provide
the same uniqueness of generic environments present prior to
serialization.
* Pack the bits for IfConfigDecls into Decl
* Don't open symbols into a module when evaluating canImport statements
The module loaders now have API to check whether a given module can be
imported without importing the referenced module. This provides a
significant speed boost to condition resolution and no longer
introduces symbols from the referenced module into the current context
without the user explicitly requesting it.
The definition of ‘canImport’ does not necessarily mean that a full
import without error is possible, merely that the path to the import is
visible to the compiler and the module is loadable in some form or
another.
Note that this means this check is insufficient to guarantee that you
are on one platform or another. For those kinds of checks, use
‘os(OSNAME)’.
Deserializing a generic environment can involve the type checker
(because it can cause the Clang importer to deserialize more), so we
cannot safely be completely lazy about a deserialized generic
environment if, e.g., SILGen or the AST verifier refers to
it. Therefore, implement a basic "pending actions" infrastructure so
that we will force the complete deserialization of any
lazily-deserialized generic environments when the outermost
deserialization of that ModuleFile occurs. This gives us the internal
laziness we need to wire up generic environments without being truly
lazy across compilation phases.
Fixes rdar://problem/29741827.
Serialization of the requirement-to-synthetic-environment map was
walking in DenseMap order. However, the keys to this map are
known---they're always the generic parameters of the requirement. So,
walk those generic parameters to make it deterministic, and don't
bother serializing them because they're known to the deserializer
already.
Fixes rdar://problem/29689811.
Serialize generic environments via a generic environment ID with a
separte offset table, so we have identity for the generic environments
and will share generic environments on deserialization.
This was in the first high level ARC instruction proposal, but I have not needed
it until now. The use case for this is to ahandle strong_retain_unowned (which
takes in an unowned value, asserts it is still alive, performs a strong_retain,
and returns the @owned value). This @owned value needs a destroy_value.
rdar://29671437
When deserializing the generic environment for a generic type, only
immediately deserialize the generic signature. The generic environment
will be deserialized later, when it's needed.
When we deserialize a function that has a generic environment, set the
generic signature and a key to allow lazy creation of the generic
environment. Because most clients won't need the generic environment,
this lets us avoid creating generic environments.
When a pattern within a type context is serialized, serialize its
interface type (not its contextual type). When deserializing, record
the interface type and keep a side table of the associated
DeclContext, so that we can lazily map to the contextual type on first
access. This is designed to break recursion when we change the way
archetypes and generic environments are serialized.
Only serialize the interface types of parameter declarations into the
module file, then lazily build the contextual types when
requested. This saves a small amount of space in the Swift module
files (~64k for the Swift standard library) and some effort on load.
