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

[Regression] java.lang.VerifyError: Incompatible object argument for function call #6572

Closed
scabug opened this issue Oct 25, 2012 · 9 comments
Closed

Comments

@scabug
Copy link

@scabug scabug commented Oct 25, 2012

This is a regression from Scala 2.9.2 and it requires specialization and separate compilation to trigger a VerifyError. Unfortunately, removing specialization causes a significant performance regression for our app.

Given:

bar/bar.scala

package bar

abstract class IntBase[V] extends Base[Int, V]

class DefaultIntBase[V <: IntProvider] extends IntBase[V] {
  override protected def hashCode(key: Int) = key
}

trait IntProvider {
  def int: Int
}

abstract class Base[@specialized K, V] {

  protected def hashCode(key: K) = key.hashCode

  def get(key: K): V = throw new RuntimeException

}

foo/foo.scala

package foo

import bar._

class FooProvider extends IntProvider {
  def int = 3
}

class Wrapper(users: DefaultIntBase[FooProvider]) {
  final def user(userId: Int) = users.get(userId)
}

object Test {
  def main(args: Array[String]) {
    new Wrapper(new DefaultIntBase)
  }
}

Steps to reproduce:

  • scalac bar/bar.scala
  • scalac foo/foo.scala
  • scala foo.Test

Expected outcome: No output.

Actual outcome:

java.lang.VerifyError: (class: foo/Wrapper, method: user signature: (I)Lfoo/FooProvider;) Incompatible object argument for function call
	at foo.Test$.main(foo.scala:15)
	at foo.Test.main(foo.scala)
@scabug
Copy link
Author

@scabug scabug commented Oct 25, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6572?orig=1
Reporter: @ijuma
Affected Versions: 2.10.0-M7, 2.10.0-RC1

Loading

@scabug
Copy link
Author

@scabug scabug commented Oct 25, 2012

@adriaanm said:
based on the resources we currently have, I'd say specialization isn't going to be fixed before 2.11.x

Loading

@scabug
Copy link
Author

@scabug scabug commented Oct 25, 2012

@paulp said:
I fixed it in master a while ago; as you can see, the fix is not in RC1. #6301, scala/scala@a3680be .

Loading

@scabug
Copy link
Author

@scabug scabug commented Oct 25, 2012

@paulp said:
I realize it's not the least bit obvious that ticket and commit have anything to do with this one; I cite it because I noticed it was fixed in master and bisected my way to it.

Loading

@scabug
Copy link
Author

@scabug scabug commented Oct 25, 2012

@ijuma said:
Hi Adriaan. I certainly understand not making major changes until 2.11.x, but it would certainly be nice to avoid regressions that cause a VerifyError. :)

Thanks Paul! A shame that it was never integrated in the 2.10.0 stream. Is there any chance it can go to 2.10.x at least?

Loading

@scabug
Copy link
Author

@scabug scabug commented Oct 25, 2012

@adriaanm said:
I just meant to set realistic expectations about stabilizing specialization as a whole. We want to focus on speed in 2.11 (aka Scala S).

If Paul has a fix already, and it doesn't cause binary incompatibilities, it seems likely to be fixed in 2.10.1.

Loading

@scabug
Copy link
Author

@scabug scabug commented Oct 25, 2012

@ijuma said:
Sure, my expectations around specialization are just "don't make it worse". I've been around for long enough. ;)

Loading

@scabug
Copy link
Author

@scabug scabug commented Jan 29, 2013

@retronym said:
Backport: scala/scala#2006

Loading

@scabug
Copy link
Author

@scabug scabug commented Feb 1, 2013

@paulp said:
36f78dd

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants