AST: Use weighted reduction order for opaque return types #81171
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
slavapestov
requested review from
jckarter,
xymus,
AnthonyLatsis,
hborla,
xedin and
eeckstein
as code owners
|
@swift-ci Please smoke test |
This is currently always 0, but can be set to 1.
If the opaque generic signature has a same-type requirement between an outer type parameter and an opaque type parameter, the former should always precede the latter in the type parameter order, even if it is longer. Achieve this by giving the innermost generic parameters a non-zero weight in the opaque generic signature. Now, when we map a type parameter into an opaque generic environment, we correctly decide if it is represented by a type parameter of the outer generic signature, in which case we apply the outer substitution map instead of instantiating an archetype. The included test case demonstrates the issue; we declare an opaque return type `some P<T.A.A>`, so the opaque generic signature has a requirement `T.A.A == <<some P>>.A`. Previously, the reduced type of `<<some P>>.A` was `<<some P>>.A`, so it remained opaque; now we apply outer substitutions to `T.A.A`. - Fixes swiftlang#81036. - Fixes rdar://problem/149871931.
slavapestov
force-pushed
the
fix-issue-81036
branch
from
5cf11bd to
8ab5ca2
Compare
|
@swift-ci Please test source compatibility |
|
@swift-ci Please smoke test macOS |
|
swiftlang/llvm-project#10587 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This fixes a bug that has been there ever since https://github.com/swiftlang/swift-evolution/blob/main/proposals/0346-light-weight-same-type-syntax.md was first implemented.
If the opaque generic signature has a same-type requirement between an outer type parameter and an opaque type parameter, the former should always precede the latter in the type parameter order, even if it is longer. Achieve this by giving the innermost generic parameters a non-zero weight in the opaque generic signature.
Now, when we map a type parameter into an opaque generic environment, we correctly decide if it is represented by a type parameter of the outer generic signature, in which case we apply the outer substitution map instead of instantiating an archetype.
The included test case demonstrates the issue; we declare an opaque return type
some P<T.A.A>, so the opaque generic signature has a requirementT.A.A == <<some P>>.A. Previously, the reduced type of<<some P>>.Awas<<some P>>.A, so it remained opaque; now we apply outer substitutions toT.A.A.