Fix/#646 array addition #667
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
odersky
force-pushed
the
fix/#646-array-addition
branch
from
80e2c36 to
4eeffb0
Compare
|
Rebased to master |
|
otherwise LGTM |
Previously, we'd see something like `? { :+: Int }`, which is confusing.
Now we see instead `? { :+ : Int }`.
Move addMode and friends to two decorators, one for Context, the other
for FreshContext. Implement behavior accordingly.
This avoids creating two contexts in situations like:
c.fresh.setxploreTyperState.addMode(...)
Mow we can write
c.fresh.addMode(...).setExploreTyperState
Because addMode returns a fresh context when applied to a fresh context.
Note that we specifically do not want virtual dispatch of addMode, that's
why it was moved to a decorator.
Also: removed mention of ".fresh: when just forllowed by an addMode, because
that one is redundant.
Test case in pending/run/array-addition.scala. The problem was that implicit search failed to insert `genericArrayOps` around `Array()`. The reason was that the implicit parameter for `genericArrayOps` was ambiguous, multiple `classTag` methods matched the expected type `ClassTag[?T >: Nothing]`. Stratifying ClassTags in DottyPredef into layers according to implicit priority avoids this problem. This is a temporary solution until we have proper ClassTag handling in place.
Previously `viewExists(X, Y)` failed if there were ambiguous
implicit conversions from X to Y. This is too fragile, as
demonstrated by test case run/array-addition.scala. Here,
the `genericArrayOps` implicit was not inserted because its
result type `Array[?T]` was deemed to be incompatible with
`? { +: : ? }`. It was incompatible because there were multiple
implicits that added :+ to arrays of various element types.
But once `genericArrayOps` gets applied, the type parameter
`?T` of the array result is fixed, and the ambuity goes away.
The scenario shows that we should not test for ambiguous implicits
in viewExists. Such a test is fragile because it depends on the
progress of type inference when the test is made. It's preferable
to just test for any implicit conversion to exist and to check
for ambiguities later, when the implicit conversion is actually
applied. This has also the potential of speeding up implicit search
in situations where `viewExists` is called often (e.g. when coupled
with overloading resolution).
odersky
force-pushed
the
fix/#646-array-addition
branch
from
6e6c6a8 to
74e9107
Compare
|
Rebased to master |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Two fixes to implicits. First, a stratification of classTag methods in DottyPredef according to priority.
Second, and more importantly, we do not check for ambiguous implicits in viewExists.
Review by @adriaanm @DarkDimius