Generalize the Mangling of Constrained Existential Types #59763
Conversation
CodaFi
force-pushed
the
mangolia
branch
2 times, most recently
from
ea60bd9 to
620e4e5
Compare
|
@swift-ci smoke test |
| appendType(EMT->getInstanceType(), sig, forDecl); | ||
| if (EMT->getInstanceType()->isExistentialType() && | ||
| EMT->hasParameterizedExistential()) | ||
| appendConstrainedExistential(EMT->getInstanceType(), sig, forDecl); |
There was a problem hiding this comment.
EMT->getInstanceType()->isExistentialType() ensures that we don't descend into them. ExistentialMetatype is only considered by isAnyExistentialType().
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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...
test/Demangle/Inputs/manglings.txt
Outdated
| $s4test3FooVAAyyAA1P_pyxqd__XPlF ---> test.Foo.test<A>(test.P<A, A1>) -> () | ||
| $s4test3FooVAAyyAA1P_pyxXPF ---> test.Foo.test(test.P<A>) -> () | ||
| $s4test3fooyyAA1P_px1TRtz_XPlF ---> test.foo<A>(any test.P<A.T == A>) -> () | ||
| $s4test3fooyyAA1P_pSS1TAaCPRtz_Si1UAERtzXPF ---> test.foo(any test.P<A.test.P.T == Swift.String, A.test.P.U == Swift.Int>) -> () |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
xedin
changed the title
CodaFi
force-pushed
the
mangolia
branch
3 times, most recently
from
22dd84b to
932ec51
Compare
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. rdar://96088707
|
@swift-ci smoke test |
|
Robert, you should not be merging patches like this with just smoke tests. |
…s for cached type relations swiftlang#59763 changed `appendType` to no longer be able to mangle `ParameterizedProtocolType`. Instead, we need to call into `appendConstrainedExistential` directly. This manifested as a SourceKit crash every time you invoke code completion when you import a module that exports a type alias that resolves to a protocol with a primary associated type. rdar://98623438
…s for cached type relations swiftlang#59763 changed `appendType` to no longer be able to mangle `ParameterizedProtocolType`. Instead, we need to call into `appendConstrainedExistential` directly. This manifested as a SourceKit crash every time you invoke code completion when you import a module that exports a type alias that resolves to a protocol with a primary associated type. rdar://98623438
…s for cached type relations swiftlang#59763 changed `appendType` to no longer be able to mangle `ParameterizedProtocolType`. Instead, we need to call into `appendConstrainedExistential` directly. This manifested as a SourceKit crash every time you invoke code completion when you import a module that exports a type alias that resolves to a protocol with a primary associated type. rdar://98623438
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