Skip to content
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

Sema: Fix handling of appliedPropertyWrappers in ConstraintSystem::replaySolution() #77475

Merged
merged 1 commit into from
Nov 8, 2024

Conversation

slavapestov
Copy link
Contributor

When we replay a solution, we must record changes in the trail, so fix the logic to do that. This fixes the first assertion failure with this test case.

The test case also exposed a second issue. We synthesize a CustomAttr in applySolutionToClosurePropertyWrappers() with a type returned by simplifyType(). Eventually, CustomAttrNominalRequest::evaluate() looks at this type, and passes it to directReferencesForType(). Unfortunately, this entry point does not understand type aliases whose underlying type is a type parameter. However, directReferencesForType() is the wrong thing to use here, and we can just call getAnyNominal() instead.

Fixes rdar://139237781.

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

Copy link
Contributor

@xedin xedin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but please fix the RUN commands for the new test.

@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

…playSolution()

When we replay a solution, we must record changes in the trail, so fix the
logic to do that. This fixes the first assertion failure with this test case.

The test case also exposed a second issue. We synthesize a CustomAttr in
applySolutionToClosurePropertyWrappers() with a type returned by simplifyType().
Eventually, CustomAttrNominalRequest::evaluate() looks at this type, and passes
it to directReferencesForType(). Unfortunately, this entry point does not
understand type aliases whose underlying type is a type parameter.
However, directReferencesForType() is the wrong thing to use here, and we
can just call getAnyNominal() instead.

Fixes rdar://139237781.
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov slavapestov enabled auto-merge November 8, 2024 20:10
@slavapestov slavapestov merged commit f702e46 into swiftlang:main Nov 8, 2024
3 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