Skip to content

@unchecked pattern binding on type with unsupported isInstanceOf fails compilation #14896

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

Closed
griggt opened this issue Apr 9, 2022 · 0 comments · Fixed by #14898
Closed

@unchecked pattern binding on type with unsupported isInstanceOf fails compilation #14896

griggt opened this issue Apr 9, 2022 · 0 comments · Fixed by #14898

Comments

@griggt
Copy link
Contributor

griggt commented Apr 9, 2022

Compiler version

3.1.2 and 3.1.3-RC1-bin-20220407-31f871c-NIGHTLY

Minimized code

This arose while working on #14294, the examples below are extracted from our test suite and modified with an @unchecked annotation.

Example 1

object Ex  { def unapply(p: Any): Option[_ <: Int] = null }
object Foo { val Ex(_) = null: @unchecked }

(extracted from tests/pos/extractor-types.scala )

Example 2

import scala.scalajs.js

object Test {
  val obj = new js.Object {
    val a = 42
    val b = "foo"
  }

  val entries = js.Object.entries(obj)
  val js.Tuple2(k, v) = entries(0): @unchecked
}

(extracted from this Scala.js test)

Output

Example 1

$ scalac extractor-types.scala

-- Error: extractor-types.scala:2:17 -------------------------------------------
2 |object Foo { val Ex(_) = null: @unchecked }
  |                 ^^^^^
  |                 class Null cannot be used in runtime type tests

Example 2

$ scalac -scalajs -cp $(cs fetch -p org.scala-js:scalajs-library_2.13:1.9.0) ObjectTest.scala

-- Error: ObjectTest.scala:10:6 ------------------------------------------------
10 |  val js.Tuple2(k, v) = entries(0): @unchecked
   |      ^^^^^^^^^^^^^^^
   |isInstanceOf[scala.scalajs.js.Tuple2] not supported because it is a JS trait

Expectation

Both examples compile without the @unchecked annotation.
Both examples compile with Scala 2.13.

Since @unchecked was added to suppress the refutable pattern binding warning (currently under -source future), I expected compilation to be successful here as well.

It seems that adding @unchecked is causing a type test to be generated that wouldn't be otherwise. Below is a diff of -Xprint:typer on the first example:

 [[syntax trees at end of                     typer]] // extractor-types.scala
 package <empty> {
   final lazy module val Ex: Ex = new Ex()
   final module class Ex() extends Object() { this: Ex.type =>
     def unapply(p: Any): Option[? >: Nothing <: Int] = null
   }
   final lazy module val Foo: Foo = new Foo()
   final module class Foo() extends Object() { this: Foo.type =>
-    null:Null @unchecked match 
+    null:Null @unchecked:Null @unchecked @unchecked match
       {
-        case Ex(_) => ()
+        case Ex(_):Null => ()
       }
   }
 }
@griggt griggt added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Apr 9, 2022
odersky added a commit to dotty-staging/dotty that referenced this issue Apr 9, 2022
With -Yexplicit-nulls Null is a class like any other. No reason to treat it specially
in type tests. Besides, as scala#14896 shows these type tests might not be user-written.

Aside: Going through the issues I have noted much higher-breakage rates than usual
in everything that concerns type test optimization and diagnostics. I don't think we
can afford much more breakage in this area. In the future, we should try harder to
err on the side of caution, which means no second guessing of what the programmer
wrote or what a previous phase generated. Default to a runtime test, unless you
know with 100% certainty that no possible scenario would be affected by that test's outcome.

Fixes scala#14896
odersky added a commit to dotty-staging/dotty that referenced this issue Apr 9, 2022
@griggt griggt added area:typer and removed stat:needs triage Every issue needs to have an "area" and "itype" label labels Apr 9, 2022
michelou pushed a commit to michelou/scala3 that referenced this issue Apr 25, 2022
@Kordyjan Kordyjan added this to the 3.2.0 milestone Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants