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
lub weirdness #5317
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5317?orig=1 |
@paulp said: type C = lub(A, B) Doesn't the definition of "lub" require that to be true? Both that ticket and this one lead to situations where it isn't. |
@paulp said: |
@paulp said: The long and the short of it is that a subtype test is done with a nullary method type on the left and a refinement on the right. The nullary result type is a subtype of the refined type, but the nullary method itself is not. Poking around I tried letting those through; then the lub is correctly calculated and everything looks good for a while, until cleanup when it crashes here: val t: Tree = ad.symbol.tpe match {
case MethodType(mparams, resType) =>
assert(params.length == mparams.length)
typedPos {
val sym = currentOwner.newValue(ad.pos, mkTerm("qual")) setInfo qual0.tpe
qual = safeREF(sym)
BLOCK(
VAL(sym) === qual0,
callAsReflective(mparams map (_.tpe), resType)
)
}
} With a match error because a TypeRef turns up. In case that's interesting. |
@paulp said: |
It seems there is a serious regression of lub between 2.9 and 2.10, which leads to illogical types.
Here is one scenario which works:
This one looks good. Now, add a field x to types S, A, B:
I would have expected to see
S { type T <: S; val x: S
as the type but instead I getScalaObject with S
.Note this is a regression from 2.9.1, where I get
ScalaObject with S{val x: ScalaObject with S; type T <: ScalaObject with S}
.Since this affects fundamental type operations I classify a solution as critical for 2.10.
The text was updated successfully, but these errors were encountered: