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

optimizer changes behavior when pattern matching Some(X) scrutinee when X's type assumed wrong #7540

scabug opened this issue May 31, 2013 · 3 comments


Copy link

scabug commented May 31, 2013

The following program produces different results depending on whether it's compiled with -optimise or not.

object Test {

  def main(args: Array[String]) {
    val s = Some(args).asInstanceOf[Option[String]]

  def m(a: Option[String]) {
    a match {
      case null => println("null")
      case None => println("None")
      case Some(x) if x == null => println("Some(null)")
      case Some(x)              => println(s"Some($x)")


Console output unoptimized:

java.lang.ClassCastException: [Ljava.lang.String; cannot be cast to java.lang.String
        at Test$.m(bt4.scala:12)
        at Test$.main(bt4.scala:5)
        at Test.main(bt4.scala)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(
        at java.lang.reflect.Method.invoke(
        . . .

Console output under -optimise :


One could argue whether:

  • it's the asInstanceOf that goes over the edge, or
  • the removal of the checkcast bytecode that went too far.

In any case, it's a behavioral difference wrt the unoptimized run (and that must be the correct one).

Copy link

scabug commented May 31, 2013

Imported From:
Reporter: @magarciaEPFL
Assignee: @JamesIry

Copy link

scabug commented May 31, 2013

@paulp said:
Maybe we should fix this example, but I don't see that we can guarantee optimized/non-optimized behavior in the face of lying casts. Many potential optimizations will depend on the type of something actually being what the type system says it is. I think fixes such as this should be best-effort at best.

@scabug scabug added this to the Backlog milestone Apr 7, 2017
Copy link

SethTisue commented Mar 2, 2018

2.12.4 is the same. regardless, closing as wontfix

@SethTisue SethTisue removed this from the Backlog milestone Mar 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

No branches or pull requests

2 participants