scalac assertion failed: TVar<Map=null> #9955
Comments
|
Imported From: https://issues.scala-lang.org/browse/SI-9955?orig=1 |
|
@SethTisue said: |
|
Qirun Zhang (helloqirun) said: I also have additional cases that can crash not only 2.12 but also 2.11 and 2.9. Does it make sense to report? |
|
@SethTisue said: |
|
Qirun Zhang (helloqirun) said: |
|
@SethTisue said: |
|
@SethTisue said: |
|
Qirun Zhang (helloqirun) said: Yes, I have a test case generator to generate syntacially valid scala code. The reported code looks weired since I have reduced the case a bit. |
|
@SethTisue said: re: "Does it make sense to report" this kind of thing: maybe! In general, we don't have the resources to even investigate, yet alone fix, just any crash. The main thing that makes a crash report valuable is minimized, easy-to-read code that triggers it. The first thing we'd do, ourselves, with any reported crash is to try to reduce it to its bare minimum essence. This, in itself, is work. And it isn't work we have time to do ourselves for just anything, so we ask that bug reporters minimize their reports themselves if at all possible. Another thing that makes a potential report valuable is how important the bug you've found is. Most bug reports are filed by programmers who were doing an actual coding task, so that's evidence right there that the issue may be encountered in practice. If you're randomly generating code, we don't that have indication, so human judgment is needed to determine whether the bug will get attention (or even whether it's worth filing in the first place). Another thing that makes a bug report valuable is information about whether the bug has been reported before. Is this really a new crash, and not just a minor variation on one we already have in JIRA? For randomly generated code, if you don't have time to determine whether the crash is new, we don't have time either. Finally, note that in general, compiler crashes are the least serious kind of compiler bug. It's always much worse if the compiler doesn't crash, but accepts incorrect code and/or produces incorrect code. Crashing at compile time isn't good, but at least the programmer knows right away they've got a problem. So: yes, it's possible that some valuable bug reports could come out of what you're doing. But producing those reports won't be easy — your code generator will only be doing a small fraction of the work for you. |
|
@paulp said: trait X {
def f[M <: M] : Any
f
} |
|
@milessabin said: |
|
@Blaisorblade said: |
|
Qirun Zhang (helloqirun) said (edited by @paulp on Oct 30, 2016 7:06:28 PM UTC): Below please find a more readable code snippet which triggers the "same" assertion failure. The code snippet (along with all my other reported issues) is generated from a testcase in the scala repository. Hope it would help. $ scalac aaa.scala
aaa.scala:5: error: illegal cyclic reference involving type T
def apply[T <: T](t: T) = new W[t.type](t)
^
aaa.scala:5: error: illegal cyclic reference involving type T
def apply[T <: T](t: T) = new W[t.type](t)
^
aaa.scala:5: error: cyclic aliasing or subtyping involving type T
def apply[T <: T](t: T) = new W[t.type](t)
^
aaa.scala:11: error: illegal cyclic reference involving type T
W("fooo").v ra_: RightAssoc
^
error: java.lang.AssertionError: assertion failed: TVar<T=null>
at scala.Predef$.assert(Predef.scala:219)
at scala.reflect.internal.Types$TypeVar.addLoBound(Types.scala:3032)
at scala.reflect.internal.tpe.TypeConstraints.$anonfun$solve$6(TypeConstraints.scala:234)
at scala.reflect.internal.tpe.TypeConstraints.$anonfun$solve$6$adapted(TypeConstraints.scala:230)
at scala.collection.immutable.List.foreach(List.scala:378)
at scala.reflect.internal.tpe.TypeConstraints.solveOne$1(TypeConstraints.scala:230)
at scala.reflect.internal.tpe.TypeConstraints.$anonfun$solve$9(TypeConstraints.scala:260)
at scala.reflect.internal.tpe.TypeConstraints.$anonfun$solve$9$adapted(TypeConstraints.scala:260)
$ cat aaa.scala
class W[T <: AnyRef](val t: T) {
val v: T {} = t
}
object W {
def apply[T <: T](t: T) = new W[t.type](t)
}
object RightAssoc {
def ra_:[T](t: T): Unit = ()
}
object Boom {
W("fooo").v ra_: RightAssoc
}
|
|
@paulp said: |
|
Qirun Zhang (helloqirun) said: |
|
Zhendong Su (zhendongsu) said: $ scalac-2.12.0 good.scala
good.scala:2: error: cyclic aliasing or subtyping involving type T
def apply[T <: T] () {}
^
error: java.lang.AssertionError: assertion failed: TVar<T=null>
at scala.reflect.internal.Types$TypeVar.addLoBound(Types.scala:3032)
at scala.reflect.internal.tpe.TypeConstraints.$anonfun$solve$6(TypeConstraints.scala:234)
at scala.reflect.internal.tpe.TypeConstraints.solveOne$1(TypeConstraints.scala:230)
at scala.reflect.internal.tpe.TypeConstraints.$anonfun$solve$9(TypeConstraints.scala:260)
at scala.reflect.internal.tpe.TypeConstraints.solve(TypeConstraints.scala:260)
at scala.reflect.internal.tpe.TypeConstraints.solve$(TypeConstraints.scala:192)
<snipped>
$
$ cat good.scala
object A {
def apply[T <: T] () {}
}
object B {
A () : Any
}
$ |
|
Unlikely to be fixed in Scala 2, crash after errors. |
|
Far from "unlikely to be fixed in Scala 2" this is fixed (in the sense that the compiler reports errors without crashing) in 2.13.0-M3, both the original example and the reduced version in the comments. |
|
you win some, you lose some. and if you lose you still win. do we have any idea what PR might have fixed it? (idle curiosity, nbd if we don't know). |
|
No idea I'm afraid. |
The following code snipped causes an assertion failure.
Update: a more readable example could be found in a comment below.
The text was updated successfully, but these errors were encountered: