More tweaks to type inference #1482
Conversation
Not used yet, but we might use it as an alternative to typedArg invalidation later.
Test case in isApplicableSafe.scala. It turns out that this
requires a context merge using the new `&' operator. Sequence of actions:
1) Typecheck argument in typerstate 1.
2) Cache argument.
3) Evolve same typer state (to typecheck other arguments, say)
leading to a different constraint.
4) Take typechecked argument in same state.
It turns out that the merge in TyperState is needed not just for
isApplicableSafe but also for (e.g. erased-lubs.scala) as well as
many parts of dotty itself.
…lement type. Test case is isApplicableSafe -Ycheck:first.
Need to export just uncommittedAncestor, can hide isCommitted and parent.
odersky
force-pushed
the
fix-asapplicable-safe
branch
from
58b1b49 to
2dfe4db
Compare
|
Rebased to master |
|
Review by @smarter? |
| // Here's the sequence of events that leads to this problem: | ||
| // | ||
| // 1. the outer Array.apply is overloaded, so we need to typecheck the inner one | ||
| // without an expected prototype |
There was a problem hiding this comment.
What if instead of giving up when this fails, we tried to re-typecheck the inner call using every possible overload? Of course this would have to be done carefully to avoid ending up like the Swift typechecker which apparently gives up when trying to compile let a: Double = -(1 + 2) + -(3 + 4) + 5 because of overloading and constraint resolutions: https://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.html
On a more general note, it seems that there is a tension in Scala caused by overloading: on one hand it significantly reduces the power of type inference, on the other hand it makes some APIs much nicer to use. So either we figure out how to get overloading to play well with type inference, or we come up with a more principled alternative to overloading that helps us keep our APIs nice.
There was a problem hiding this comment.
Yeah, I am very nervous about trying all combinations. That typically leads to blowup in compile times. Then you either become too restrictive and can't even typecheck trivial expressions or your compile times go through the roof. In both cases there's little a programmer can do.
|
The commit message for 3664854 says:
Looks like a word is mising after |
|
Otherwise LGTM |
| targetState.constraint = constraint | ||
| targetState.constraint = | ||
| if (targetState.constraint eq previousConstraint) constraint | ||
| else targetState.constraint & constraint |
There was a problem hiding this comment.
The commit message of 3664854 explains why merging is needed but this is tricky enough that it should also be explained in a comment here.
|
I'll add the note wrt merging in the next PR. |
It turned out we need to merge constraints when backtracking, after all.