Once we compute a generic signature from a generic signature builder,
all queries involving that generic signature will go through a separate
(canonicalized) builder, and the original builder can no longer be used.
The canonicalization process then creates a new, effectively identical
generic signature builder. How silly.
Once we’ve computed the signature of a generic signature builder, “register”
it with the ASTContext, allowing us to move the existing generic signature
builder into place as the canonical generic signature builder. The builder
requires minimal patching but is otherwise fully usable.
Thanks to Slava Pestov for the idea!
This is somewhat of a pyrrhic victory, because it was just a shell over
resolvePotentialArchetype() anyway, but we now have fewer entry points that
produce potential archetypes.
We shouldn’t need a potential archetype to map an interface type to a
contextual type. Port `getTypeInContext()` over to `EquivalenceClass`,
largely unchanged, so we don’t directly form archetypes.
Kills a few more uses of `GenericSignatureBuilder::resolveArchetype()`.
The anchor of an equivalence class canonically represents that equivalence
class. Add API for computing the anchor directly, and switch a few more
clients off of `resolveArchetype()`.
The type checker shouldn’t know about potential archetypes. Use
GenericSignatureBuilder::resolveEquivalenceClass() and perform the lookup
into that instead.
The test case change highlights an existing problem with generic signature
minimization.
Funnel all places where we create a generic signature builder to compute
the generic signature through a single entry point in the GSB
(`computeGenericSignature()`), and make `finalize` and `getGenericSignature`
private so no new uses crop up.
Tighten up the signature of `computeGenericSignature()` so it only works on
GSB rvalues, and ensure that all clients consider the GSB dead after that
point by clearing out the internal representation of the GSB.
We had two similar loops that performed name lookup for nested types on a
potential archetype, so consolidate those into a single implementation on
the equivalence class itself.
Managing equivalence classes via the implicit structure of potential
archetypes is silly, and leads to weird patterns where we visit all
potential archetypes just to find the equivalence classes. Teach the
GSB implementation to manage equivalence classes in a linked list, so we
can easily iterate over them, and switch most uses of
`visitPotentialArchetypes()` over to that iteration.