[5.1][ConstraintSystem] Consolidate logic forming locators to callees #25782
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
This commit adds `ConstraintSystem::getCalleeLocator`, which forms a locator that describes the callee of a given expression. This function is then used to replace various places where this logic is duplicated. This commit also changes the conditions under which a ConstructorMember callee locator is formed. Previously it was formed for a CallExpr with a TypeExpr function expr. However, now such a locator is formed if the function expr is of AnyMetatypeType. This allows it to be more lenient with invalid code, as well as work with DotSelfExpr. Resolves SR-10694. (cherry picked from commit 894a1e5)
Currently we check that the fixes share the same anchor, however this doesn't account for the case where, given an ApplyExpr, one fix is anchored on its function expr, and another is anchored on the apply itself (because the former fix might be looking at the callee's requirements, and the latter fix might be looking at an argument of the call). This commit changes the logic such that we check that fixes share the same callee locator, which covers the above case. In addition, now that we have the callee locator, we can use this to find the overload directly. (cherry picked from commit 63df26a)
This helps clean up a bunch of call sites. (cherry picked from commit 8aa7401)
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
If we're cherry-picking this, could we also cherry-pick 40d2f51 to make sure we don't start resolving callee overloads for |
|
@hamishknight Absolutely! |
|
@swift-ci please test |
|
Build failed |
|
Build failed |
Previously we returned a subscript member locator for an apply of a subscript expr, which is incorrect because the callee is the function returned from the subscript rather than the subscript itself. (cherry picked from commit 40d2f51)
xedin
force-pushed
the
callee-locator-logic-consolidation-5.1
branch
from
7fe1bd2 to
a0a4a5b
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
Seems like this is good to merge! I hope this fixes my other PR 🤞 |
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 PR adds
ConstraintSystem::getCalleeLocator, which forms a locator that describes the callee of a given expression. This function is then used to replace various places where this logic is duplicated, and in doing so improves a couple of diagnostics due to catching cases that were previously missed. Most notably, it's now more lenient when forming aConstructorMemberlocator for an apply. Previously such a locator was only formed for an apply of aTypeExpr, however now it's formed for an apply of an expr ofAnyMetatypeType. This better matches the logic insimplifyApplicableFnConstraintand allows us to better diagnose things liketype(of: x)(...).getCalleeLocatoris then used when checking if we can diagnose an ambiguity with fixes, which allows us to have fixes anchored to both the apply and to its function expr (where the former could be looking at an argument of the apply, and the latter could be looking at a requirement of the callee).Finally, this PR adds a convenience
getDeclOrNullfunction toOverloadChoice, and fixes a simple compiler crasher. Given how straightforward these changes were, I didn't feel it was worth splitting them into a separate PR.Resolves SR-10694 and SR-10696.