SI-7753 InstantiateDependentMap narrows type of unstable args #3507
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
|
This continues where #3482 left off. |
|
No, I don't mean "fix it", I mean put it in as a neg test which should eventually be pos. |
| ){converted.instance.Out}; | ||
| */ | ||
|
|
||
| val v2: Int = indirect(conv(foo))(23) // Fails. |
There was a problem hiding this comment.
You might want to rebase the comment out as it's a bit misleading now that this is a pos test.
|
I'll send you a PR. That test is freaking poetry. |
Merged
|
test comment improved |
We've started calling this method during higher-kinded subtyping to ensure that variances of higher order type params in overriding as soundly aligned. Turns out that running this over the expansion of the SBT task macro leads to a SOE due to a corrupt owner chain. I've fixed that in SBT (sbt/sbt#1113), but we ought not crash like this. This commit considers NoSymbol to be its own enclosing member and logs a -Xdev warning. This is analagous to the handling of `NoSymbol.owner`.
|
LGTM. |
I noticed the change when adapting Slick to work with Scala 2.11 in `AbstractSourceCodeGenerator.scala`. The behaviour changed in a70c821. This commit locks down the new, correct behaviour with a test.
|
Will rebase on master once #3516 is merged |
Avoid SOE in logicallyEnclosingMember
A test case for a name binding progression
SI-8177 co-evolve more than just RefinedTypes
[Most of this comment and the initial fix were implemented by Jason Zaugg.
I just cleaned it up a bit.]
After a soundness fix in SI-3873, instantiation of dependent
method type results behaved differently depending on whether the argument
from which we were propagating information had a stable type
or not. This is particular to substitution into singleton types
over the parameter in question.
If the argument was stable, it was substituted into singleton
types, such as the one below in the prefix in `a.type#B`
(which is the longhand version of `a.B`)
scala> class A { type B >: Null <: AnyRef }
defined class A
scala> object AA extends A { type B = String }
defined object AA
scala> def foo(a: A): a.B = null
foo: (a: A)a.B
scala> foo(AA)
res0: AA.B = null
But what if it isn't stable?
scala> foo({def a = AA; a: A { type B <: String}})
res1: a.B = null
This commit changes that to:
scala> foo({def a = AA; a: A { type B <: String}})
res1: A{type B <: String}#B = null
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.
[Most of this comment and the initial fix were implemented by Jason Zaugg.
I just cleaned it up a bit.]
After a soundness fix in SI-3873, instantiation of dependent
method type results behaved differently depending on whether the argument
from which we were propagating information had a stable type
or not. This is particular to substitution into singleton types
over the parameter in question.
If the argument was stable, it was substituted into singleton
types, such as the one below in the prefix in
a.type#B(which is the longhand version of
a.B)scala> class A { type B >: Null <: AnyRef }
defined class A
scala> object AA extends A { type B = String }
defined object AA
scala> def foo(a: A): a.B = null
foo: (a: A)a.B
scala> foo(AA)
res0: AA.B = null
But what if it isn't stable?
scala> foo({def a = AA; a: A { type B <: String}})
res1: a.B = null
This commit changes that to:
scala> foo({def a = AA; a: A { type B <: String}})
res1: A{type B <: String}#B = null
review by @retronym