-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Type alias for dependent function type expanded incorrectly when nested #5592
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
Comments
The compiler seems to crash because it's trying to construct the And of two method types (which are not value types as defined in the spec), instead of two function types (which are, and can be combined in an intersection), but it's not clear why MethodTypes would be there — or even why an and is being constructed (tho that might be ok). Replacing type Foo = [x] => (y: Obj) => (x =::= y.type) => (y.type =::= x)
val eqSymmetric2: Forall[Foo] = {
{ x: Obj => { y: Obj => { xEqy: x.type =::= y.type => xEqy.commute } } }
}
|
Fix #5592: Fix & of method type refinements
Although the crash is resolved in 158ccd7, I believe the test which was added by this commit should not be a negative test, since I expect the types of For reference, the code on
|
In `distributeAnd` we need to combine refinements in the same way denotation infos are combined, with special treatement of method and poly types.
@Blaisorblade the issue (of the wrong/unintuitive alias expansion) does not seems to be resolved. Would you mind reopening this? |
I can’t look closely, but the output seems indeed nonsensical. At the very least I can’t tell where y’ comes from. In fact, that’s another variable named y, which the compiler adds a ‘ to, to point out it’s not the same as y. Why that’d be the case, I don’t know. |
I believe there is a separate bug in the pretty print of the error message here. For example, take
In the Required section, there is a type |
Re pretty-print: to be sure x’ is not a legal name in Scala. The ‘ is added to distinguish different identifiers which happen to have the same name. In other words, to undo shadowing. I filed a bug about this because I also find it misleading. So, in the message you quote, the compiler thinks there are two identifiers named x, and they are different. Which is even correct, since x’ is a type variable, and Forall instantiates it to x.type. However, maybe x should indeed be x’ in Forall[[x]; that would indeed be a pretty-printing bug. |
I was having a close look on the following code, which I expect to compile: object Test {
def assertEqType[A, B >: A <: A]: Unit = Unit
def assertSubType[A, B >: A]: Unit = Unit
{
// type error(does not conform to lower bound A)
assertSubType[
(x: Unit) => ((y: Unit) => x.type =:= y.type),
([F[_]] => (z: Unit) => F[z.type])[[x] => (y: Unit) => x =:= y.type]
]
// compiles
assertEqType[
([F[_]] => (z: Unit) => F[z.type])[[x] => ([F[_]] => (z: Unit) => F[z.type])[[y] => x =:= y]],
([F[_]] => (z: Unit) => F[z.type])[[x] => (y: Unit) => x =:= y.type]
]
}
} checking the typed tree of the code, it seems like the type (Unit =>
((Unit => =:=[_, _]) {
def apply(y: Unit): =:=[_, _]
})
) {
def apply(x: Unit): (Unit => =:=[x.type, _]) {
def apply(y: Unit): =:=[x.type, y.type]
}
} and the type (Unit =>
((Unit => =:=[_, _]) {
def apply(y: Unit): =:=[_, y.type]
})
) {
def apply(z: Unit): (Unit => =:=[z.type, _]) {
def apply(y: Unit): =:=[z.type, y.type]
}
} which is actually a subtype of the first one. Since the type lambda version is somehow giving a more concrete type, I believe these issues come from parent type in the (refined) expansion of dependent type. Is there any particular reason why we need to calculate the upper bound |
Closing for inactivity and a lack of direction what should be done here. |
It looks like this is fixed by #11847 |
Approximating type maps should not compute illegal unreducible wildcard applications. Instead they should propagate the Range outwards Fixes scala#5592
Approximating type maps should not compute illegal unreducible wildcard applications. Instead they should propagate the Range outwards Fixes scala#5592
Approximating type maps should not compute illegal unreducible wildcard applications. Instead they should propagate the Range outwards Fixes scala#5592
This occurs on the latest
master
.For the code below, the type of
eqSymmetric1
,eqSymmetric2
andeqSymmetric3
should all be equivalent.However, when
eqSymmetric2
is included, the compiler crashes with:and when
eqSymmetric3
is included, a type error is given:The text was updated successfully, but these errors were encountered: