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

java.lang.VerifyError when defining extractors for traits which are subtypes #3702

Closed
scabug opened this issue Jul 25, 2010 · 4 comments
Closed
Assignees
Labels
Milestone

Comments

@scabug
Copy link

scabug commented Jul 25, 2010

When I have two traits, Test1 and Test2, and Test2 is a subtype of Test1, and I define two extractors for these traits, a java.lang.VerifyError is thrown at runtime when I try to use the extractors in a pattern match statement. Consider the REPL output:

$$ scala
Welcome to Scala version 2.8.0.r0-b20100714201327 (Java HotSpot(TM) Server VM, Java 1.6.0_20).
Type in expressions to have them evaluated.
Type :help for more information.

scala> trait Test1 {
     | def f1: Int
     | }
defined trait Test1

scala> trait Test2 extends Test1 {
     | def f2: Int
     | }
defined trait Test2

scala> object Test1 {
     | def unapply(t1: Test1): Option[(Int)] = Some(t1.f1)
     | }
defined module Test1

scala> object Test2 {
     | def unapply(t2: Test2): Option[(Int,Int)] = Some(t2.f1, t2.f2)
     | }
defined module Test2

scala> case class Test2Impl() extends Test2{
     | def f1 = 1
     | def f2 = 2
     | }
defined class Test2Impl

scala> val a: AnyRef = Test2Impl()
a: AnyRef = Test2Impl()

scala> a match {
     | case Test2(a,b) => println("a: " + a)    
     | case Test1(a) => println(a)
     | }
java.lang.VerifyError: (class: , method: <init> signature: ()V) Accessing value from uninitialized register 4
    at RequestResult$$.<init>(<console>:9)
    at RequestResult$$.<clinit>(<console>)
    at RequestResult$$scala_repl_result(<console>)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at scala.tools.nsc.Interpreter$$Request$$$$anonfun$$loadAndRun$$1$$$$anonfun$$apply$$18.apply(Interpreter.scala:981)
    at scala.tools.nsc.Interpreter$$Request$$$$anonfun$$loadAndRun$$1$$$$anonfun$$apply$$18.apply(Interpreter.scala:981)
    at scala.util.control.Exception$$Catch.apply(Exception....
scala> 

This problem isn't just limited to the REPL, but also for compiled code. See the attached file (which is just this REPL session in a file)

@scabug
Copy link
Author

scabug commented Jul 25, 2010

Imported From: https://issues.scala-lang.org/browse/SI-3702?orig=1
Reporter: Stephen Tu (stephentu)
Attachments:

@scabug
Copy link
Author

scabug commented Aug 18, 2010

Margus Freudenthal (margus) said:
I stumbled on a similar problem when trying to match parse tree produced by ANTLR treebuilder. The code runs under Scala 2.7 and fails under 2.8 (VerifyError). Interesting point: if I delete the line "g = " " from + ".." + to", then the program runs correctly under Scala 2.8.

See attachment test_match2.scala

@scabug
Copy link
Author

scabug commented Feb 28, 2011

@paulp said:
The test_match attachment minimized is:

  def foo(h: Any, t: List[Any]) = h match {
    case 5 :: _ => ()
    case List(from) => from
  }

This one is a buzzkill because it looks to arise from the pattern matcher cheating on case List(...) in a way it doesn't with anything else so as to offer the same performance (i.e. not use unapplySeq.) Thus there is special code for treating List like it's a series of :: and someone, me we can presume, has broken that code.

I'm not sure it's the same issue as the reporter's, except that the pattern matcher can legitimately be viewed as one giant issue.

@scabug
Copy link
Author

scabug commented May 11, 2012

@soc said:
Fixed in scala/scala@4c04213

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

No branches or pull requests

2 participants