Skip to content

[6.2] AST: Fix existential erasure of long member types #81182

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 30, 2025

Conversation

slavapestov
Copy link
Contributor

@slavapestov slavapestov commented Apr 29, 2025

6.2 cherry-pick of #81181

  • Description: Fixes a compiler crash in some circumstances when erasing a type parameter that is rooted in a primary associated type of an existential value.

  • Origination: The regression shipped in Swift 6.1.

  • Reviewed by: @AnthonyLatsis

  • Risk: Low. This changes a frequently-called code path, but I believe it's well-tested. The isValidTypeParameter() check does not assert on invalid inputs, and it returns true in all cases that the old check returned true.

@slavapestov slavapestov requested a review from a team as a code owner April 29, 2025 22:06
@slavapestov slavapestov changed the title AST: Fix existential erasure of long member types [6.2] AST: Fix existential erasure of long member types Apr 29, 2025
Suppose protocol P has a primary associated type A, and we have
a `any P<S>` value. We form the generalization signature <T>
with substitution map {T := S}, and the existential signature
<T, Self where T == Self.A>.

Now, if we call a protocol requirement that takes Self.A.A.A,
we see this is fixed concrete type, because the reduced type of
Self.A.A.A is T.A.A in the existential signature.

However, this type parameter is not formed from the
conformance requirements of the generalization signature
(there aren't any), so we cannot directly apply the outer
substitution map.

Instead, change the outer substitution conformance lookup
callback to check if the reduced type parameter is valid
in the generalization signature, and not just rooted in a
generic parameter of the generalization signature.

If it isn't, fall back to global conformance lookup.

A better fix would introduce new requirements into the
generalization signature to handle this, or store them
separately in the generic environment itself. But this is fine
for now.

- Fixes swiftlang#79763.
- Fixes rdar://problem/146111083.
@slavapestov slavapestov force-pushed the fix-issue-79763-6.2 branch from 239e77c to 9bb6673 Compare April 29, 2025 23:00
@slavapestov
Copy link
Contributor Author

@swift-ci Please test

@slavapestov slavapestov merged commit 75181f9 into swiftlang:release/6.2 Apr 30, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants