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

[SR-7617] 'value of type has no member' for apply expressions #50159

Open
AnthonyLatsis opened this issue May 6, 2018 · 5 comments
Open

[SR-7617] 'value of type has no member' for apply expressions #50159

AnthonyLatsis opened this issue May 6, 2018 · 5 comments
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation improvement type checker Area → compiler: Semantic analysis

Comments

@AnthonyLatsis
Copy link
Collaborator

Previous ID SR-7617
Radar None
Original Reporter @AnthonyLatsis
Type Improvement
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement, DiagnosticsQoI, TypeChecker
Assignee None
Priority Medium

md5: 3877c08aab495ca9c8a4b47e6bc0efb9

Issue Description:

The type checker does not treat UnresolvedDotExpression and ApplyExpr differently when diagnosing unviable member lookup results. This would give us a chance to reduce the candidate list based on the arguments provided and generate a more accurate diagnostic.

struct Foo {

  func doo() {}

  func roo(_ arg: Int, _ arg2: Int) {}

}

let foo = Foo()

_ = foo.moo(4, 6) // Value of type 'Foo' has no member 'moo'

// Did you mean 'doo'?
// Did you mean 'roo'?

// Should only ask about 'roo'
@belkadan
Copy link
Contributor

belkadan commented May 7, 2018

Please don't tag something as a starter bug unless you pretty much know yourself how you'd fix it. (If someone else asked you to do so, please mention them, since they're on the hook for helping the newcomer who tries to implement it.)

@xedin, is this StarterBug material?

@AnthonyLatsis
Copy link
Collaborator Author

@belkadan Understood. Regarding this particular case, I do have a idea of how to fix it since it's related to something I am fixing right now (It's not hard). Most likely I'll be fixing it myself soon.

@xedin
Copy link
Member

xedin commented May 7, 2018

I'm not really sure, because we already treat `UnresolvedDotExpr` and `ApplyExpr` differently in diagnostics code. @AnthonyLatsis I think what you really want here is to improve `diagnoseMemberFailures` and typo correction code to detect moo as possible misspelling of `doo` or `roo`, WDYT?

@AnthonyLatsis
Copy link
Collaborator Author

@xedin I was not clear enough: I meant that, as a general rule, for ApplyExpr with an UnresolvedDotExpr base, the base is type-checked first, which often results in inaccurate diagnostics due to context lacking. For instance, foo.moo(3, 4) is typechecked as foo.moo (literaly as a member), which is the reason unnecessary candidates are shown. For foo.moo, we have to show all the candidates, but for foo.moo(...), we can filter based on the arguments. Right now (as far as I can see) diagnoseMemberFailures doesn't work with apply expressions. If we fix that and make a call to it at visitApplyExpr, we can improve and diagnose taking arguments into account before calling diagnoseUnviableLookupResults.
This will also fix the need to place member-applyExpr specific diagnostics in visitApplyExpr. How about it?

@xedin
Copy link
Member

xedin commented May 7, 2018

@AnthonyLatsis I think it's a good idea, and I've tried to do make changes multiple times already without success because it always breaks more complex expressions or expressions with errors in different positions, the problem is the bottom-up type-checking used for diagnostics and presence of contextually dependent expressions, which doesn't allow us to pin-point error location. I'm hoping to start working on the different approach which is going to record errors in the solver to aid with error locating, that should solve this problem.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler The Swift compiler in itself diagnostics QoI Bug: Diagnostics Quality of Implementation improvement type checker Area → compiler: Semantic analysis
Projects
None yet
Development

No branches or pull requests

3 participants