RequirementMachine: Overhaul handling of protocol typealiases with concrete underlying type #41773
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Consider this example:
Recall that the concrete typealias introduces a rule of the form:
This overlaps with the conformance rule (
T.[P] => T
) on the termT.[P].A
to produce the ruleT.A.[concrete: Int] => T.A
.Now the generic signature equates the associated type
T.[P:B]
with the typealiasT.A
via an abstract same-type requirement, which introduces a rewrite rule of the form:This overlaps with
T.A.[concrete: Int] => T.A
onT.A.[concrete: Int]
, so we get a new rule:For compatibility with the GenericSignatureBuilder, this final rule is the one we want to turn into a requirement in the minimal signature (T.B == Int); we don't want to keep (T.B == T.A) around.
To get this behavior, don't consider eliminating (
T.[P:B].[concrete: Int] => T.[P:B]
) via a rewrite loop containing any protocol typealias rules, in this case, ([P].A.[concrete: Int] => [P].A
).This trick only works because the left hand side of a protocol typelias rule is always greater than an associated type in the reduction order, since terms with name symbols are always greater than terms without name symbols.
There is a more general problem here where we fail to produce a signature compatible with the GenericSignatureBuilder in other similar cases that do not involve protocol typealiases, for example here we should transform
U.Element == Character
:A solution to the above problem will subsume this hack, but for now, let's land it to move forward.
Fixes https://bugs.swift.org/browse/SR-15924 / rdar://problem/89641526.