Skip to content

Properly recover from nested ambiguous implicit search failures #9937

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 2 commits into from
Oct 3, 2020

Conversation

smarter
Copy link
Member

@smarter smarter commented Oct 2, 2020

From
http://dotty.epfl.ch/docs/reference/changed-features/implicit-resolution.html:

The treatment of ambiguity errors has changed. If an ambiguity is
encountered in some recursive step of an implicit search, the ambiguity
is propagated to the caller.

This is supposed to be handled by healAmbiguous but the implementation
was incorrect: it compared pending candidates against the two ambiguous
results from the search, but this doesn't make sense when the failure
happened in a nested search: for example in i9793, the failure is:

Applied.bazApplied[F](/* ambiguous: both value baz and value bar match type Foo[F] */summon[Foo[F])

We should be able to recover from this failure because barApplied is
more specific than bazApplied, but before this commit we ended up
comparing barApplied to baz and bar which isn't meaningful.

Fixes #9793.

This commit does not change the compiler behavior but replaces
`compareCandidate` by a more generic `compareAlternatives` that will be
useful in the next commit, this required introducing a base trait
`RefAndLevel` (not a great name, but I couldn't think of anything
better...).
From
http://dotty.epfl.ch/docs/reference/changed-features/implicit-resolution.html:

> The treatment of ambiguity errors has changed. If an ambiguity is
> encountered in some recursive step of an implicit search, the ambiguity
> is propagated to the caller.

This is supposed to be handled by `healAmbiguous` but the implementation
was incorrect: it compared pending candidates against the two ambiguous
results from the search, but this doesn't make sense when the failure
happened in a nested search: for example in `i9793`, the failure is:

    Applied.bazApplied[F](/* ambiguous: both value baz and value bar match type Foo[F] */summon[Foo[F])

We should be able to recover from this failure because `barApplied` is
more specific than `bazApplied`, but before this commit we ended up
comparing `barApplied` to `baz` and `bar` which isn't meaningful.

Fixes scala#9793.
@smarter smarter added this to the 3.0.0-M1 milestone Oct 2, 2020
@smarter smarter requested a review from odersky October 2, 2020 15:50
Copy link
Contributor

@odersky odersky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@odersky odersky merged commit 7f46c25 into scala:master Oct 3, 2020
@odersky odersky deleted the nested-ambiguous-2 branch October 3, 2020 14:28
@Kordyjan Kordyjan modified the milestones: 3.0.0-M1, 3.0.0 Aug 2, 2023
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.

Nested implicit ambiguity error is not recovered from correctly
3 participants