-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[CS] Resolve callees for key path components #27087
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
Conversation
In order to do this we need it to take a ConstraintLocator argument so we can tell which component we want the callee for. To make it clear that we're looking for a callee at the anchor, also rename the member to getAnchormostCalleeLocator.
Have FailureDiagnostic::getChoiceFor take a ConstraintLocator argument which is passed through to getAnchormostCalleeLocator, and rename to getAnchormostChoiceFor to make the semantics clear. In addition, add a convenience getAnchormostChoice member for the common case of getting the choice for the anchor of the failure's locator. This change means we can now resolve callees for failures associated with key path subscript components. Resolves SR-11435.
@swift-ci please test |
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.
Looks great! I like updated logic but I not sure sure about the naming, maybe we should keep names the same? When it comes to key path component locators I think original naming still makes sense, if locator points to a component you get a locator to retrieve overload choice associated with that component.
@xedin Thanks for the quick review! I'm happy to keep the same namings, my only concern was that if you gave functionA(functionB())
^^^^^^^^^^^
"leaf"
^^^^^^^^^^^^^^^^^^^^^^
anchor you might expect to receive a callee locator that describes |
@hamishknight I think that's something we could document in the comment for In my opinion solution for it would be for calls to propagate locators down to its arguments during constraint generation, so |
In addition, add a document comment to `getCalleeLocator` to clarify its semantics.
@xedin Fair enough, I've gone ahead and reverted the naming changes as well as expanded on the doc comment for If that all looks good to you, I'll go ahead and smoke test + merge :) |
@hamishknight Looks great, let's |
@swift-ci please smoke test and merge |
1 similar comment
@swift-ci please smoke test and merge |
@swift-ci please smoke test Linux platform |
1 similar comment
@swift-ci please smoke test Linux platform |
This PR changes
getCalleeLocator
such that it now takes aConstraintLocator
argument, allowing it to resolve callees for cases where we have aKeyPathExpr
base and aKeyPathComponent
locator element. To make it clear that we're looking for a callee at the anchor, this PR also renames it togetAnchormostCalleeLocator
(open to alternative naming suggestions).This change is then plumbed through to CSDiagnostics, where
getAnchormostChoiceFor
can be used to get the choice for the anchor of a given locator. Finally, agetAnchormostChoice
member has been added to make the common case of getting the choice made for the anchor of the failure more convenient.Resolves SR-11435.