The old syntax was
@opened("UUID") constraintType
Where constraintType was the right hand side of a conformance requirement.
This would always create an archetype where the interface type was `Self`,
so it couldn't cope with member types of opened existential types.
Member types of opened existential types is now a thing with SE-0309, so
this lack of support prevented writing SIL test cases using this feature.
The new syntax is
@opened("UUID", constraintType) interfaceType
The interfaceType is a type parameter rooted in an implicit `Self`
generic parameter, which is understood to be the underlying type of the
existential.
Fixes rdar://problem/93771238.
Add handling for repeated specialization and remove an incorrect
assertion in
ExistentialTransform::createExistentialSpecializedFunctionName():
assert(!F->getModule().hasFunction(MangledName));
The ExistentialSpecializer replaces the original function with a thunk
to a newly specialized function. Repeated attempts to specialize the
same function bail out because the pass avoids reoptimizing thunks.
Ultimately, the intention is that the thunks will all be inlined into
their callers. Dead function elimination will then remove the
thunks. If the original function was itself a specialization, then the
GenericSpecialize may regenerate the original again in non-thunk form.
Consider the pipeline:
- GenericSpecializer
- ExistentialSpecializer
- Inliner
- DeadFunctionElimination
- GenericSpecializer
- ExistentialSpecializer
This is not a problem with the ExistentialSpecializer itself. In fact,
it may respecialize the same function in different ways, for example
specializing more of the arguments each time. Each different
specialization transforms the original function into a thunk, that
thunk is inlined, and the newly specialized code is called directly.
Of course, the ExistentialSpecializer may also decide to respecialize
a function the same way as before. When doing this, it still needs to
produce the thunk, which was dead function eliminated since last
specialization of the same function. However, it can simply reuse the
previous specialization by performing a name lookup first.
The design problem is that the SILModule makes assumptions about
duplicate symbols when managing symbol memory but does not provide a
robust way to protect against such duplicate symbols. That will be
improved in a separate commit.
Minimal fix for: rdar://72135512 The ExistentialSpecializer crashes
