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

refinement+function+override=VerifyError: Illegal use of nonvirtual function call #7992

Closed
scabug opened this issue Nov 22, 2013 · 4 comments
Assignees
Milestone

Comments

@scabug
Copy link

scabug commented Nov 22, 2013

Reproduce code:

object Test extends App{
  (new Child).mkInner(null)
}
class Child extends Parent{
  override def mkInner =
    c => {
      if(false) new Inner{}
  	  else super.mkInner(null)
    }
}
class Parent{
  def mkInner: Any => Inner = _ => new Inner
  class Inner
}

Expected result:
Compiles and runs fine

Actual result:

java.lang.VerifyError: (class: Child$$anonfun$mkInner$1, method: apply signature: (Ljava/lang/Object;)LParent$Inner;) Illegal use of nonvirtual function call
	at Child.mkInner(verifyError.scala:6)
	at Test$delayedInit$body.apply(verifyError.scala:2)
	at scala.Function0$class.apply$mcV$sp(Function0.scala:40)
	at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:12)
	at scala.App$$anonfun$main$1.apply(App.scala:71)
	at scala.App$$anonfun$main$1.apply(App.scala:71)
	at scala.collection.immutable.List.foreach(List.scala:318)
	at scala.collection.generic.TraversableForwarder$class.foreach(TraversableForwarder.scala:32)
	at scala.App$class.main(App.scala:71)
	at Test$.main(verifyError.scala:1)
	at Test.main(verifyError.scala)
	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.util.ScalaClassLoader$$anonfun$run$1.apply(ScalaClassLoader.scala:71)
	at scala.tools.nsc.util.ScalaClassLoader$class.asContext(ScalaClassLoader.scala:31)
	at scala.tools.nsc.util.ScalaClassLoader$URLClassLoader.asContext(ScalaClassLoader.scala:139)
	at scala.tools.nsc.util.ScalaClassLoader$class.run(ScalaClassLoader.scala:71)
	at scala.tools.nsc.util.ScalaClassLoader$URLClassLoader.run(ScalaClassLoader.scala:139)
	at scala.tools.nsc.CommonRunner$class.run(ObjectRunner.scala:28)
	at scala.tools.nsc.ObjectRunner$.run(ObjectRunner.scala:45)
	at scala.tools.nsc.CommonRunner$class.runAndCatch(ObjectRunner.scala:35)
	at scala.tools.nsc.ObjectRunner$.runAndCatch(ObjectRunner.scala:45)
	at scala.tools.nsc.MainGenericRunner.runTarget$1(MainGenericRunner.scala:74)
	at scala.tools.nsc.MainGenericRunner.process(MainGenericRunner.scala:96)
	at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:105)
	at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)
@scabug
Copy link
Author

scabug commented Nov 22, 2013

Imported From: https://issues.scala-lang.org/browse/SI-7992?orig=1
Reporter: @cvogt
Affected Versions: 2.9.3, 2.10.3, 2.11.0-M7

@scabug
Copy link
Author

scabug commented Feb 18, 2014

@gkossakowski said:
Given the fact that it's not regression and we are really late before RC1 I decided to push to Scala 2.11.1.

@scabug
Copy link
Author

scabug commented Mar 15, 2014

@retronym said:
scala/scala#3634

@scabug scabug closed this as completed Apr 21, 2014
@scabug
Copy link
Author

scabug commented Aug 18, 2014

Alex Garthwaite (alextg) said:
FWIW we ran into this issue upgrading code from 2.9.3 to 2.10.4 at Twitter. The patch fixes the problem in Jason's pull request (as does simple code refactoring).

The code in question looked like:

    def render(... args ...) = {
        out.in(str1) { ... out.in(str2) { ... } }
    }

The result compiled fine but let to VerifyErrors when the class file was loaded. Contrary to what is listed above, this code compiled and ran fine with 2.9.3. It is only broken with 2.10.4. Diffing the bytecode that is generated, the 2.9.3 code uses a longer sequence using invokevirtual whereas the 2.10.4 code uses a very short invokespecial sequence.

Given that it appears this is a regression in behavior, does it make sense to apply the fix to 2.10.5?

p.s. The workaround I took was to lift the body of the second argument to the "out.in(str1) {...}" expression out as a separate def.

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