Generalize the Mangling of Constrained Existential Types

[CodaFi]

Upgrade the old mangling from a list of argument types to a
list of requiremnets. For now, only same-type requirements
may actually be mangled since those are all that are available
to the surface language.

Reconstruction of existential types now consists of demangling (a list of)
base protocol(s), decoding the constraints, and converting the same-type
constraints back into a list of arguments. Which is simple to do at the moment
because the only kinds of same-type constraints we have are rooted at
dependent types of Self.

rdar://96088707

[CodaFi]

@swift-ci smoke test

[rjmccall]

Metatypes can be nested

[CodaFi]

EMT->getInstanceType()->isExistentialType() ensures that we don't descend into them. ExistentialMetatype is only considered by isAnyExistentialType().

[rjmccall]

Okay, so if we don't need to descend into nested metatypes here, why do we need to call out direct existential metatypes at all instead of just letting the recursive visitation in appendType handle it?

[rjmccall]

Like, my patch to symbolically reference shapes does need to do something at this level because the existential metatype is part of the shape, but I think the normal mangling path doesn't have to. You'll just get down to the ExistentialType and do what you need to do at that level.

[CodaFi]

why do we need to call out direct existential metatypes at all instead of just letting the recursive visitation in appendType handle it?

The AST for any P<T>.Type currently looks like (ExistentialMetatypeType (ParameterizedProtocolType ...)) which is unfortunate...

[rjmccall]

Oof, this demangling is super confusing. I guess we're in a generic context that says τ_0_0 is such-and-such type? Maybe we can push a different context when the LHS of these?

This ties in with my concern about using requirements here — it's really a false economy, because τ_0_0 means different things in different positions in the requirement. And you still don't have the ability to express things like P<.Slice == .self>, because you can't write τ_0_0 on the RHS without it being ambiguous in case you're actually in a generic context.

[rjmccall]

If you want to stick with mangling requirements, you could just build them in terms of some new "protocol self" base type that's guaranteed to mangle differently from other types. Or you could use Requirement internally in the compiler when building + uniquing things and then do a special-case mangling at the last minute.

[CodaFi]

@swift-ci smoke test

[rjmccall]

Robert, you should not be merging patches like this with just smoke tests.