Skip to content

[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

Merged
merged 4 commits into from
Sep 10, 2019

Conversation

hamishknight
Copy link
Contributor

@hamishknight hamishknight commented Sep 9, 2019

This PR changes getCalleeLocator such that it now takes a ConstraintLocator argument, allowing it to resolve callees for cases where we have a KeyPathExpr base and a KeyPathComponent locator element. To make it clear that we're looking for a callee at the anchor, this PR also renames it to getAnchormostCalleeLocator (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, a getAnchormostChoice 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.

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.
@hamishknight hamishknight requested a review from xedin September 9, 2019 13:28
@hamishknight
Copy link
Contributor Author

@swift-ci please 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.

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.

@hamishknight
Copy link
Contributor Author

@xedin Thanks for the quick review! I'm happy to keep the same namings, my only concern was that if you gave getCalleeLocator a locator such as:

functionA(functionB())
          ^^^^^^^^^^^
             "leaf"
^^^^^^^^^^^^^^^^^^^^^^
        anchor

you might expect to receive a callee locator that describes functionB rather than functionA (and you might not realise that simplifying the locator will change how getCalleeLocator behaves). What do you think?

@xedin
Copy link
Contributor

xedin commented Sep 9, 2019

@hamishknight I think that's something we could document in the comment for getCalleeLocator but I'm not sure we can/want to do much about that, that's why diagnostics have getAnchor() and getRawAnchor().

In my opinion solution for it would be for calls to propagate locators down to its arguments during constraint generation, so visit*Expr methods would not only get an expression pointer but also a ConstraintLocatorBuilder that way constraints/type variables associated with functionB() in your example would always get a locator rooted in the call.

In addition, add a document comment to `getCalleeLocator` to clarify
its semantics.
@hamishknight
Copy link
Contributor Author

@xedin Fair enough, I've gone ahead and reverted the naming changes as well as expanded on the doc comment for getCalleeLocator. Also given that getChoiceFor(getLocator()) is no longer too onerous to write, I've removed the convenience member for that.

If that all looks good to you, I'll go ahead and smoke test + merge :)

@xedin
Copy link
Contributor

xedin commented Sep 9, 2019

@hamishknight Looks great, let's :shipit:

@hamishknight
Copy link
Contributor Author

@swift-ci please smoke test and merge

1 similar comment
@hamishknight
Copy link
Contributor Author

@swift-ci please smoke test and merge

@hamishknight
Copy link
Contributor Author

@swift-ci please smoke test Linux platform

1 similar comment
@hamishknight
Copy link
Contributor Author

@swift-ci please smoke test Linux platform

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