Introduce an operation to check that a given substitution map is non-empty
(i.e., corresponds to a generic signature) and that the generic signature
has type parameters that aren’t bound to concrete types. This is the
appropriate predicate for SIL-and-later to determine whether there
will be any substitutions.
SubstitutionMap::lookupSubstitution() assumed that any type parameter it was
given would already be canonical, and fail (return a null Type) when given
a type parameter that was equivalent to another type parameter but is
not itself canonical. Canonicalize, recursive, and record the replacement
type appropriately.
Every SubstitutionMap::toList() invocation would ASTContext-allocate
arrays for all of the conformances, then return a SmallVector of the
underlying substitutions, which both wastes memory *and* puts the onus
on the caller to allocate a copy of that outer SmallVector into the
ASTContext if it's going to be stored anywhere.
Stop the madness by caching an ASTContext-allocated SubstitutionList
within the storage for the SubstitutionMap. This both reduces repeated
allocations and eliminates the potential for errors.
Now that SubstitutionMap is used in so many places, reduce it's header
dependencies by moving SubstitutionMap::Storage into its own separate
implementation header. Use forward declarations of other entities
(GenericSignature, Substitution) instead.
Good for build times and general sanity.
Replace two prominent uses of SubstitutionList, in ConcreteDeclRef and
Witness, with SubstitutionMap. Deal with the myriad places where we
now have substitution maps and need substitution lists (or vice versa)
caused by this change.
Overall, removes ~50 explicit uses of SubstitutionList (of ~400).
Prepare for SubstitutionMaps to be stored in other AST nodes by making
them ASTContext-allocated and uniqued (via a FoldingSet). They are now
cheap to copy and have trivial destructors.
Collapse the out-of-line array of replacement types and the DenseMap used
for conformances into a single field that references out-of-line,
tail-allocated storage for all of the contents of a SubstitutionMap.
The conformances are now represented as a flat array whose indices
line up with the indices of the conformance requirements in the
underlying generic signtature.
Reference this storage via a single shared_ptr, so that copies of
SubstitutionMaps are cheap but we aren't (yet) uniqueing them or
storing them within the ASTContext.
The primary implementation for substituting into substitution maps was
cloning the contents of the SubstitutionMap and then performing
in-place updates to the (new) data structure, which both had too many
dependencies on the data structure and subverted some of the checking
we get through the normal path.
Reimplement this function in terms of
GenericSignature::getSubstitutionMap(), which is the primary/canonical
way to form a substitution map.
The generic signature used to perform substitutions for a BoundNameAliasType
in ill-formed code might not line up with the generic signature in the
typealias. Separately record the signature we used to build the
BoundNameAliasType to make the AST more robust against such issues.
Introduce a new Type node, BoundNameAliasType, which describes a
reference to a typealias that requires substitutions to produce the
underlying type. This new type node is used both for references to
generic typealiases and for references to (non-generic) typealiases
that occur within generic contexts, e.g., Array<Int>.Element.
At present, the new type node is mainly useful in preserving type
sugar for diagnostics purposes, as well as being reflected in other
tools (indexing, code completion, etc.). The intent is to completely
replace NameAliasType in the future.
Conformances that discoverably for a type parameter via a superclass
requirement occupy a bit of a gray area in the type checker and
generic signature handling right now: we have a type parameter (so the
paths that handle concrete conformances don't kick in), but the
conformance itself isn't modeled as a requirement because it is
available via lookup. Teach SubstitutionMap's conformance lookup to
detect this case and perform conformance lookup in the generic
signature (i.e., falling back to global lookup) in this case,
replicating the hack that IRGen uses to address the same issue when
accessing the conformance (see GenArchetype.cpp's TODO where we lookup
a conformance on the superclass). The removal of that hack (as well as
this one) are tracked by rdar://problem/34609744.
For now, fixes SR-7072 / rdar://problem/37904576.
This will allow key paths to resiliently reference public properties from other binaries by referencing a descriptor vended by the originating binary. NFC yet, this just provides printing/parsing/verification of the new component.
The enclosing conformance-lookup operation can fail (i.e., it returns
Optional), but the nested call was force-unwrapping the optional from
an inner call for no particular reason. Stop doing that, which fixes
SR-6466.
Note that the offending code is still something that should go away in
time, so this is merely polishing the band-aid to avoid a crash that
occurs often with conditional conformances.
If there's no lazy resolver and we're looking at an incomplete conformance,
fail with an error instead of crashing. The caller will likely crash also,
but at least this allows better recovery in this case in the future.
When an archetype conforms to a protocol abstractly (ie, it is
not class-constrained and we don't have any further information
other than that it conforms), we can recover nested types,
but we cannot recover the conformance of those nested types
to protocols if those conformances are concrete (the nested
type might be concrete, or it might be a class-constrained
archetype).
To work around this, we added a hack where if the conformance
lookup in the SubstitutionMap fails, we fall back to the module.
This is horrible and unprincipled, but has to remain in place
until more infrastructure is plumbed through.
Commit 620db5f74c made this
workaround apply in fewer cases, so that we could still catch
cases where the SubstitutionMap was constructed with missing
conformances.
Unfortunately this workaround didn't handle the case where the
nested type was an archetype with a superclass constraint.
This will all go away soon, but for now tweak the logic a bit,
since I really want to keep the "narrow" workaround in place
and not the general fallback, otherwise we run the risk of
SubstitutionMap conformance lookup bitrotting completely.
Fixes <https://bugs.swift.org/browse/SR-4088> and
<rdar://problem/32773028>.
The replacement types in a SubstitutionMap correspond with the generic
parameters of its generic signature, so replace the DenseMap storage
with a flat array of Types, one element for each generic parameter.
If SubstitutionMap is asked to form a substitution for a generic
parameter that has been made concrete by the generic signature,
substitute into the concrete type. This allows us to better deal with
non-canonical types.
SubstitutionMap::lookupConformance() would map archetypes out
of context to compute a conformance path. Do the same thing
in SubstitutionMap::lookupSubstitution().
The DenseMap of replacement types in a SubstitutionMap now
always has GenericTypeParamTypes as keys.
This simplifies some code and brings us one step closer to
a more efficient representation of SubstitutionMaps.
This manifested as test/Prototypes/PatternMatching.swift failing
under 'ninja check-swift-validation-optimize'.
I'll add a test later if I have time to reduce a test case, but this
whole hack is hopefully going away soon anyway.
Fixes one of the three failures outlined in <rdar://problem/31780356>.
Instead of just falling back to module lookup any time conformance
substitution fails, only do it in the case we know doesn't work.
This should shake out some more bugs, hopefully without causing
too much pain.
When asking a substitution map for a conformance, it's okay if the
conformance isn't there---just detect this case and return None.
Also, collapse a redundant testcase Huon noted.
When looking for a conformance for an archetype, map it out of context
to compute the conformance access path, then do the actual lookups
based on mapping the starting type back into the context. Eliminate
the parent map and "walk the conformances" functionality.
When looking up a particular conformance in a SubstitutionMap, use the
associated generic signature to determine how to find that conformance
(via a conformance access path). Follow that conformance access path
to retrieve the desired conformance.
FIXME: There is still one failure, here
Constraints/generic_overload.swift
which appears to be because we either have the wrong generic signature
for the override case or we are looking in the wrong map.
Substitution maps are effectively tied to a particular generic
signature or environment; keep track of that signature/environment so
that we can (eventually) use it to find conformances.
We go to look at the conforming protocols of an associated type
but we haven't built the generic environment for the associated
type's protocol yet.
In the test case given, we find the conformance later via a
different path, so everything continues to work.
SubstitutionMap::lookupConformance() is hopefully getting a
makeover soon, and this hack will go away.
Fixes <rdar://problem/31302713>.
We should enable it again once the substitutions machinery and GenericSignatureBuilder always generate correct SubstitutionMaps.
But for now let’s disable it to unblock the CI jobs.
Should fix SR-4322 and rdar://31224655
