Skip to content
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

poor diagnostic error for using newly-generified Java class got even worse #8439

Open
scabug opened this issue Mar 24, 2014 · 7 comments
Open

Comments

@scabug
Copy link

scabug commented Mar 24, 2014

2.11.0-M1, amongst an projectile error:

Exception in thread "main" java.lang.Error: something is wrong (wrong class file?): class JList with type parameters [E] gets applied to arguments [], phase = typer

2.11.0-M2:

something is wrong: cannot make sense of type application
  E
  javax.swing.JList

2.11.0-M3

Exception in thread "main" java.lang.IndexOutOfBoundsException: 0
	at scala.collection.LinearSeqOptimized$class.apply(LinearSeqOptimized.scala:51)
	at scala.collection.immutable.List.apply(List.scala:85)
	at scala.reflect.internal.tpe.TypeMaps$AsSeenFromMap.correspondingTypeArgument(TypeMaps.scala:552)

Minimization pending.

@scabug
Copy link
Author

scabug commented Mar 24, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8439?orig=1
Reporter: @retronym
Affected Versions: 2.11.0-M2
See #4365

@scabug
Copy link
Author

scabug commented Mar 24, 2014

@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)

@scabug
Copy link
Author

scabug commented Mar 24, 2014

@retronym said:
Yeah, my diagnosis is still a bit circumstantial, there might be two bugs here.

@scabug
Copy link
Author

scabug commented Mar 24, 2014

@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.

@scabug
Copy link
Author

scabug commented Mar 25, 2014

@retronym said:
Standalone test:

object Test {
  val lv: scala.swing.ListView[Any] = ???
  lv.peer.setModel(null)
}

@scabug
Copy link
Author

scabug commented Mar 25, 2014

@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 :(

@scabug
Copy link
Author

scabug commented Jun 20, 2014

@gourlaysama said:
Another example, from this scala-user thread:

object Test extends App {
  val comboBox = new ComboBox(List(None))
  comboBox.peer.setModel(new DefaultComboBoxModel())
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants