Open scabug opened 10 years ago
Imported From: https://issues.scala-lang.org/browse/SI-8439?orig=1 Reporter: @retronym Affected Versions: 2.11.0-M2 See #4365
@adriaanm said: This method was the cause for another crash reported by Sciss on scala-internals. It looks at typeParams (which dealiases behind the scenes) to derive an index into typeArgs (which doesn't dealias)
@retronym said: Yeah, my diagnosis is still a bit circumstantial, there might be two bugs here.
@adriaanm said (edited on Mar 25, 2014 12:03:01 AM UTC):
EDIT: the below is wrong (and I should be commenting on the other ticket, but I got pre-empted so let me brain dump), the bounds seen in this line: val repl = if (variance.isPositive) dropSingletonType(tp1.bounds.hi) else tp1.bounds.lo
are wrong already
I've been poking around here a bit as well, which made me circle back to the hack in #4365. Ugh. Looks like the root cause of the symbol mismatch over there is TypeMaps going off the rails:
case PolyType(tparams, result) =>
val tparams1 = flipped(mapOver(tparams))
val result1 = this(result)
if ((tparams1 eq tparams) && (result1 eq result)) tp
else PolyType(tparams1, result1.substSym(tparams, tparams1))
The problem is that result
is a type that correctly refers to tparams
, but this connection is lost when tparams1
and result1
are transformed separately, so that by the time we do result1.substSym(tparams, tparams1)
, the symbols in tparams
no longer occur in result1
.
@retronym said: Standalone test:
object Test {
val lv: scala.swing.ListView[Any] = ???
lv.peer.setModel(null)
}
@retronym said:
private def correspondingTypeArgument(lhs: Type, rhs: Type): Type = {
val TypeRef(_, lhsSym, lhsArgs) = lhs
val TypeRef(_, rhsSym, rhsArgs) = rhs
require(lhsSym.owner == rhsSym, s"$lhsSym is not a type parameter of $rhsSym")
// Find the type parameter position; we'll use the corresponding argument.
// Why are we checking by name rather than by equality? Because for
// reasons which aren't yet fully clear, we can arrive here holding a type
// parameter whose owner is rhsSym, and which shares the name of an actual
// type parameter of rhsSym, but which is not among the type parameters of
// rhsSym. One can see examples of it at SI-4365.
val argIndex = rhsSym.typeParams indexWhere (lhsSym.name == _.name)
// don't be too zealous with the exceptions, see #2641
if (argIndex < 0 && rhs.parents.exists(typeIsErroneous))
// no type args as scala.swing.ListView was compiled against JDK6
Test.lv.peer.type baseType JList = JList
lhs = type E(in JList)
lhsArgs = {scala.collection.immutable.Nil$@2623}"Nil$" size = 0
lhsSym = {scala.reflect.internal.Symbols$AbstractTypeSymbol@2622}"type E"
rhs = JList
// But, in this compilation run ListView has sprouted type parameters.
rhsSym.typeParams = [type E]
// So we think we'll find E among lhsArgs at:
argIndex = 0
// but we IIOBE instead :(
@gourlaysama said: Another example, from this scala-user thread:
object Test extends App {
val comboBox = new ComboBox(List(None))
comboBox.peer.setModel(new DefaultComboBoxModel())
}
2.11.0-M1, amongst an projectile error:
2.11.0-M2:
2.11.0-M3
Minimization pending.