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

[scabug]

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]]
    m(s)
  }

  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(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        . . .

Console output under -optimise :

Some([Ljava.lang.String;@4cd96e86)

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).

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-7540?orig=1
Reporter: @magarciaEPFL
Assignee: @JamesIry

[scabug]

@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.

[SethTisue]

2.12.4 is the same. regardless, closing as wontfix