Skip to content

Fix #5773: Apply more context info to avoid ambiguous implicits #5836

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 13 commits into from
Feb 7, 2019

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Feb 3, 2019

In the absence of a proper fix for #5773 (which is problematic since it would affect implicit search oder),
we still can give a better error message.

EDIT: We now have a full fix, but it's still good to have the better error messages.

In implicit search, if both contextual and type search fail,
pick the more significant error of the two searches to report.

 - ambiguous trumps other errors
 - otherwise, errors with larger computed results trump errors with smaller ones.
Copy link
Member

@dottybot dottybot left a comment

Choose a reason for hiding this comment

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

Hello, and thank you for opening this PR! 🎉

All contributors have signed the CLA, thank you! ❤️

Commit Messages

We want to keep history, but for that to actually be useful we have
some rules on how to format our commit messages (relevant xkcd).

Please stick to these guidelines for commit messages:

  1. Separate subject from body with a blank line
  2. When fixing an issue, start your commit message with Fix #<ISSUE-NBR>:
  3. Limit the subject line to 72 characters
  4. Capitalize the subject line
  5. Do not end the subject line with a period
  6. Use the imperative mood in the subject line ("Add" instead of "Added")
  7. Wrap the body at 80 characters
  8. Use the body to explain what and why vs. how

adapted from https://chris.beams.io/posts/git-commit

Have an awesome day! ☀️

@odersky odersky changed the title Fix #5773: Better error messages for failed extension messages Partial Fix for #5773: Better error messages for failed extension messages Feb 3, 2019
smarter added a commit to lampepfl/scala that referenced this pull request Feb 3, 2019
smarter added a commit to lampepfl/scala that referenced this pull request Feb 3, 2019
smarter added a commit to lampepfl/scala that referenced this pull request Feb 3, 2019
A subtype test `A <:< P` where `P` is a prototype was implemented
as `P.isMatchedBy(A)`. `isMatchedBy` did not keep the constraint
which meant that information was lost instead of being propagated.
Don't cache the result of an unforced typedArgs if it is
a WildcardType. We might come back later and want the forced
version.
@odersky
Copy link
Contributor Author

odersky commented Feb 3, 2019

test performance please

@dottybot
Copy link
Member

dottybot commented Feb 3, 2019

performance test scheduled: 1 job(s) in queue, 0 running.

Drop all IgnoredProto parts of the expected type before
inferring the arguments of an implicit method. That way,
we propagate all available info by `constrainResult`
into the current constraint before doing the implicit
search. This prevents ambiguity errors. See pos/i5773.scala.
When doping a deepenProto, strip all levels of IgnoredProto, not just one.
@dottybot
Copy link
Member

dottybot commented Feb 3, 2019

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/5836/ to see the changes.

Benchmarks is based on merging with master (03887b7)

If an inferred argument is ambiguous, try to deepen the prototyoe,
and if that succeeds, try again.
@odersky
Copy link
Contributor Author

odersky commented Feb 3, 2019

Some improvements of type inference now make this work. And it seems they also help performance (a bit). In a nutshell:

  • Make comparisons with prototypes influence the current constraint
  • Reveal previously ignored parts of prototypes when encountering an
    ambiguous implicit, analogous to what we do on ambiguous overload.
  • Immediately reveal ignored parts of prototypes for extension methods
    to avoid going through ambiguous implicits failures (that's just an optimization).

@odersky odersky requested a review from smarter February 3, 2019 23:11
@odersky odersky changed the title Partial Fix for #5773: Better error messages for failed extension messages Fix #5773: Apply more context info to avoid ambiguous implicits Feb 4, 2019
// So we'd get a "inconsistent: no typevars were added to committable constraint"
// assertion failure in `constrained`. To do better, we'd have to change the
// constraint handling architecture so that some type parameters are committable
// and others are not. But that's a whole different ballgame.
Copy link
Member

Choose a reason for hiding this comment

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

Could we add a pending test that demonstrates the current limitation here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't have a test for this (but agree it would be good to have one).

@odersky odersky merged commit 8726cf7 into scala:master Feb 7, 2019
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.

3 participants