Equivalence classes stored their same-type constraints in a MapVector
keyed on the source potential archetype, which allowed traversal along the
paths of the graph. However, this capability isn't required, because we
end up walking all of the edges each time. Flatten the list of same-type
constraints to a single vector, eliminating constraint duplication between
the source and the target out-edge lists.
This cuts down on the number of same-type constraints we record by 50%,
but performance gains are limited (6% of stdlib type-checking time)
because most of the time these same-type constraints were skipped
anyway.
When computing connected components for the graph of derived same-type
constraints within an equivalence, replace the depth-first search with
union-find. The latter does not require us to have an out-edges list
for each node in the graph.
Now that getBuilder() is gone, stash an ASTContext into root
PotentialArchetypes instead of a GenericSignatureBuilder. This eliminates
some ickiness where we had to re-root potential archetypes when moving a
GenericSignatureBuilder.
Refactor the interfaces that involve “walking” a requirement source
(e.g., minimization, computation of the affected type, etc.) to rely
only on interface types and not potential archetypes.
We're now getting the right set of potential archetypes, so this hack is
just extraneous work. Reduces the number of lookups into the
equivalence class nested type cache by ~24%, but only improves
type-checking performance of the standard library by ~3%.
We want to delay the realization of potential archetypes as late as
possible; for layout constraints, push realization of potential archetypes
down past the point where we know whether we’re learning anything new
about the equivalence class.
No functionality change, yet.
Any potential archetype with the lowest depth in the equivalence class
will do when we're resolving for equivalence classes, so keep the
lowest-depth potential archetype handy.
Teach GenericSignatureBuilder::resolveEquivalenceClass() to perform
resolution of a type into a dependent type and its equivalence class
without realizing that potential archetype. Improves type-checking
time for the standard library by ~6%.
We want to be able to resolve a type to a particular known equivalence class
without realizing the corresponding potential archetype. Represent this in
ResolveResult, even though we're not using this state yet.
When we're only resolving the equivalence class in which a dependent type
occurs, always use the archetype anchor for the equivalence class to
find the equivalence class of the next nested type. This means that,
for example, determining the equivalence class of
C.SubSequence.SubSequence.SubSequence.SubSequence for a Collection C
will only resolve potential archetypes up to
C.SubSequence.SubSequence.
Not much benefit from this because the GenericSignatureBuilder itself
isn't using resolveEquivalenceClass() when expanding requirements.
Prior to the removal of the “lookup conformance function”, whenever
the type checker created a GenericSignatureBuilder, its lookup conformance
function would mark any referenced conformance as “used”. Do so now via
a LazyResolver callback, which fixes a regression in multi-file type
checking scenarios.
Now that the GenericSignatureBuilder is no longer sensitive to the input
module, stop uniquing the canonical GSBs based on that module. The main
win here is when deserializing a generic environment: we would end up
creating a canonical GSB in the module we deserialized and another
canonical GSB in the module in which it is used.
Implement a module-agnostic conformance lookup operation within the GSB
itself, so it does not need to be supplied by the code constructing the
generic signature builder. This makes the generic signature builder
(closer to) being module-agnostic.
Now that we only record potential archetypes involving the "anchor"
archetypes, there is no need to collapse structurally-equivalent potential
archetypes. Delete some temporary code.
When we have an equivalence class that contains two unrelated
associated types with the same name, infer a same-type constraint
between those two associated types. This is a more principled way to
introduce these constraints that we had before, fixing a
recently-introduced regression.
Since overriding associated types aren't recorded as potential archetypes,
there is no point in introducing inferred same-type constraints involving
them.
Use the "override" information in associated type declarations to provide
AST-level access to the associated type "anchor", i.e., the canonical
associated type that will be used in generic signatures, mangling,
etc.
In the Generic Signature Builder, only build potential archetypes for
associated types that are anchors, which reduces the number of
potential archetypes we build when type-checking the standard library
by 14% and type-checking time for the standard library by 16%.
There's a minor regression here in some generic signatures that were
accidentally getting (correct) same-type constraints. There were
existing bugs in this area already (Huon found some of them), while
will be addressed as a follow-up.
Fies SR-5726, where we were failing to type-check due to missed
associated type constraints.
