-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Fix implicit search failure reporting #20261
Conversation
|
||
retyped | ||
else | ||
val res = untpd.Apply(tree, args).withType(firstFailure.get) |
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.
Before we would use the first non-ambiguous error if there is one; here I simplified it to just use the first error.
@odersky commented on #19414 that:
Ambiguous implicits often arise when something else is failing (for instance a variable was not instantiated enough). That's why we try to find first other errors. That was the thinking behind the current semantic. [...]
But I think this is not relevant anymore after the changes in this PR; as we're anyway reporting all errors by recursively visiting the argument trees.
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.
Let's discuss how we can be the functionality of "I found" in the error messages before a more detailed code review.
tests/neg/implicitSearch.check
Outdated
| Test.listOrd[List[T]](Test.listOrd[T](/* missing */summon[Test.Ord[T]])) | ||
| | ||
| But no implicit values were found that match type Test.Ord[T]. | ||
| No given instance of type Test.Ord[T] was found for parameter o of method listOrd in object 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.
The change in parameter name is good, but I think we should keep the "I found" part of the error message. Otherwise it's not clear why a listOrd is required in the first place. The "I found" part tells you that.
Instead, fix the display of nested `AmbiguousImplicits` errors.
I tried something a bit different to keep the "I found" messages. The problematic case with the current infrastructure (apart from handling default arguments) is really ambiguous implicit that are nested. In this case, we just bubble the error up and the error message then use the wrong param names, but all the other cases are fine. So, to solve this, I tried to just add a This approach leaves all existing tested message outputs unchanged, but only fixes the new test cases. |
@odersky: I changed the message to be "No best given [...]" for ambiguous implicits, as discussed. |
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.
Nice!
Potential regression: #20344. |
This reverts one part of scala#20261. When we fail with both an ambiguity on one implicit argument and another error on another we prefer the other error. I added a comment why this is needed. Fixes scala#20354
This reverts one part of scala#20261. When we fail with both an ambiguity on one implicit argument and another error on another argument we prefer the other error. I added a comment why this is needed. Fixes scala#20344
…uity on one implicit argument and another error on another argument we prefer the other error. I added a comment why this is needed.
…on one implicit argument and another error on another argument we prefer the other error. I added a comment why this is needed.
Backports #20261 to the LTS branch. PR submitted by the release tooling. [skip ci]
Fixes #19414.