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.
Instead of creating an archetype builder with a module---which was
only used for protocol conformance lookups of concrete types
anyway---create it with a LookupConformanceFn. This is NFC for now,
but moves us closer to making archetype builders more canonicalizable
and reusable.
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.
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.
Like c70a5a5d67, but for deserialization. This was causing assertion
failures during the merge-module step of building a module that had a
private/fileprivate protocol with an associated type because the
associated type wouldn't have a valid private discriminator (because
the original source file didn't consider it to be private).
https://bugs.swift.org/browse/SR-2576
The handling of SIL box types in both deserialization and in the SIL
parser assumed that the number of substitutions in the box type would
be equivalent to the number of generic parameters. This assumption is
incorrect when the generic signature adds requirements to an
associated type.
Fixes rdar://problem/29740594.
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.
Fixes SR-2757.
Variables in capture lists are treated as 'let' constants, which can
result in misleading, incorrect diagnostics. Mark them as such in order
to produce better diagnostics, by adding an extra parameter to the
VarDecl initializer.
Alternatively, these variables could be marked as implicit, but that
results in other diagnostic problems: capture list variables that are
never used produce warnings, but these warnings aren't normally emitted for
implicit variables. Other assertions in the compiler also misfire when
these variables are treated as implicit.
Another alternative would be to walk up the AST and determine whether
the `VarDecl`, but there doesn't appear to be a way to do so.
- The DeclContext versions of these methods have equivalents
on the DeclContext class; use them instead.
- The GenericEnvironment versions of these methods are now
static methods on the GenericEnvironment class. Note that
these are not made redundant by the instance methods on
GenericEnvironment, since the static methods can also be
called with a null GenericEnvironment, in which case they
just assert that the type is fully concrete.
- Remove some unnecessary #includes of ArchetypeBuilder.h
and GenericEnvironment.h. Now changes to these files
result in a lot less recompilation.
When deserializing a SIL generic environment, don't form generic type
parameter declarations that would have empty names; they print poorly
(as <anonymous>), breaking SIL parsing of the result.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
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.
- TypeAliasDecl::getAliasType() is gone. Now, getDeclaredInterfaceType()
always returns the NameAliasType.
- NameAliasTypes now always desugar to the underlying type as an
interface type.
- The NameAliasType of a generic type alias no longer desugars to an
UnboundGenericType; call TypeAliasDecl::getUnboundGenericType() if you
want that.
- The "lazy mapTypeOutOfContext()" hack for deserialized TypeAliasDecls
is gone.
- The process of constructing a synthesized TypeAliasDecl is much simpler
now; instead of calling computeType(), setInterfaceType() and then
setting the recursive properties in the right order, just call
setUnderlyingType(), passing it either an interface type or a
contextual type.
In particular, many places weren't setting the recursive properties,
such as the ClangImporter and deserialization. This meant that queries
such as hasArchetype() or hasTypeParameter() would return incorrect
results on NameAliasTypes, which caused various subtle problems.
- Finally, add some more tests for generic typealiases, most of which
fail because they're still pretty broken.
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.
We were only setting the “requires class” bit when it was true. When it was false, semantic analysis would end up taking the slow path to compute the “false”, which is wasted effort.
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.
A pointless use of polymorphism -- the result values are not
interchangeable in any practical sense:
- For GenericTypeParamDecls, this returned getDeclaredInterfaceType(),
which is an interface type.
- For AssociatedTypeDecls, this returned the sugared AssociatedTypeType,
which desugars to an archetype.
- For TypeAliasDecls, this returned TypeAliasDecl::getAliasType(),
which desugars to a type containing archetypes.
- For NominalTypeDecls, this returned NominalTypeDecl::getDeclaredType(),
which is the unbound generic type, a special case used for inferring
generic arguments when they're not written in source.
This eliminates the really gross registration of archetype builders
within the ASTContext, and is another little step toward lazily
constructing archetypes.
Stop recording specific archetypes anywhere in
PotentialArchetype. Instead, use a GenericEnvironment to record/query
the archetype that corresponds to that PotentialArchetype, making it
possible to use the same archetype builder (and its potential
archetypes) to build multiple generic environments.
