-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[CSApply] A couple of locator adjustments to support updated Double<->CGFloat conversion #59902
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
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
@swift-ci please test |
@swift-ci please test source compatibility |
hborla
approved these changes
Jul 7, 2022
@swift-ci please test |
@swift-ci please test source compatibility |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NFC remarks only (not worth relaunching already triggered tests).
Double/CGFloat implicit conversion expects a full locator (array-expr + tuple-element <idx>) to find selected overload.
…onary key/value Original locator carries information about key and value types which is necessary for diagnostics but cannot be retrieved in its original state during solution application, so it could be dropped from Double<->CGFloat constructor locator.
Just like in case of array elements, the locator needs to much what was produced by constraint generator otherwise Double<->CGFloat implicit coercion wouldn't be able to find the overload choice.
…nation type Constraint generator records conversion between source and destination types as anchored on an assignment, which means that coercion has to do the same in case restrictions (like Double<->CGFloat conversion) depend on locators to retrieve information for the solution.
The locator needs to much what was produced by constraint generator otherwise Double<->CGFloat implicit coercion wouldn't be able to find the overload choice.
@swift-ci please smoke test |
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.
#59762 made it possible to use Double<->CGFloat conversions in different
arguments positions of the same call, but it didn't account for the fact that
some locators are constructed incorrectly by
ExprRewriter
during solutionapplication.
This PR adjusts locators for the following situations:
<collection> -> tuple element #
locator;itself since this is where the conversion constraint is placed (which is also very helpful for diagnostics).
Resolves: rdar://96469597
Resolves: rdar://96477064
Resolves: rdar://96477058
Resolves: #59932