Skip to content

Fix #2300: Try to heal subtype failures by instantiating type variables #2896

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 7 commits into from
Jul 25, 2017

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jul 20, 2017

The idea is that if an adapt fails because an actual type A is not a
subtype of an expected type B, we try to instantiate all type variables
in A and, if that changes something, try again.

This mitigates the discrepancy that dotc is more lazy in instantiating type
variables than scalac.

Fixes #2300.

odersky added 7 commits July 20, 2017 22:17
…riables

The idea is that if an adapt fails because an actual type A is not a
subtype of an expected type B, we try to instantiate all type variables
in A and, if that changes something, try again.

This mitigates the discrepancy that dotc is more lazy in instantiating type
variables than scalac.

Fixes scala#2300.
Commit only if the adapt following the instantiation is
error-free. DottyLanguageServer had a compilation failure
due to the previous scheme.
DottyLanguageServer contained an example that shows that we
should not instantiate type variables before trying an implicit
conversion.
Copy link
Member

@smarter smarter left a comment

Choose a reason for hiding this comment

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

LGTM, much simpler than I thought it would be!

@DarkDimius DarkDimius merged commit 30dba8c into scala:master Jul 25, 2017
@liufengyun
Copy link
Contributor

The latest speedup most likely comes from this PR -- due to some reordering of the commits, the graph doesn't point to the correct PR.

@smarter
Copy link
Member

smarter commented Jul 26, 2017

due to some reordering of the commits, the graph doesn't point to the correct PR.

Can you explain that? What reordering of commits? It'd be good if the graph was accurate.

@liufengyun
Copy link
Contributor

Now it's clear -- the drop is due to my restarting of the testing server this morning. I've fixed the CPU to a determined frequency, the restart lost the setting.

Now I restored the setting (permanent), re-ran all tests for this morning and the graphs are explainable. The graph does point to the correct PRs.

@allanrenucci allanrenucci deleted the fix#-2300 branch December 14, 2017 16:59
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.

4 participants