Safer exceptions throw ClassCastException

[romanowski]

Compiler version

Scala 3.1.1-RC1-bin-SNAPSHOT-git-3a6a949 (16.0.1, Java OpenJDK 64-Bit Server VM)

Minimized code

The following code compiles, but produces a runtime exception:

import language.experimental.saferExceptions

trait Decoder[+T]:
  def apply(): T

given Decoder[Int throws Exception] = new Decoder[Int throws Exception]:
  def apply(): Int throws Exception = 1

@main def run(): Unit =
  import unsafeExceptions.canThrowAny
  summon[Decoder[Int throws Exception]]()

Output

java.lang.ClassCastException: class java.lang.Integer cannot be cast to class scala.Function0 (java.lang.Integer is in module java.base of loader 'bootstrap'; scala.Function0 is in unnamed module of loader java.net.URLClassLoader @59ec2012)
        at throwing.throws$package$.run(throws.scala:13)
        at throwing.run.main(throws.scala:11)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:567)
        at dotty.tools.runner.RichClassLoader$.run$extension$$anonfun$1(ScalaClassLoader.scala:95)
        at dotty.tools.runner.RichClassLoader$.asContext$extension(ScalaClassLoader.scala:30)
        at dotty.tools.runner.RichClassLoader$.run$extension(ScalaClassLoader.scala:95)
        at dotty.tools.runner.CommonRunner.run(ObjectRunner.scala:23)
        at dotty.tools.runner.CommonRunner.run$(ObjectRunner.scala:13)
        at dotty.tools.runner.ObjectRunner$.run(ObjectRunner.scala:48)
        at dotty.tools.runner.CommonRunner.runAndCatch(ObjectRunner.scala:30)
        at dotty.tools.runner.CommonRunner.runAndCatch$(ObjectRunner.scala:13)
        at dotty.tools.runner.ObjectRunner$.runAndCatch(ObjectRunner.scala:48)
        at dotty.tools.MainGenericRunner$.run$1(MainGenericRunner.scala:178)
        at dotty.tools.MainGenericRunner$.main(MainGenericRunner.scala:206)
        at dotty.tools.MainGenericRunner.main(MainGenericRunner.scala)

Expectation

Successful execution.

Note that changing the given definition to this will eliminate the exception:

given Decoder[Int throws Exception] with
  def apply(): Int throws Exception = 1

[odersky]

This looks like a fundamental mismatch between context functions and erased functions. There's an optimization that integrates a context function into a method, like this:

def apply(): CanThrow ?=> T

becomes

def apply(using CanThrow): T

In the example, the apply actually overrides an apply method defined in Decoder like this:

def apply(): T

That's OK, since we will just add a bridge method:

def apply(): CanThrow ?=> Int = apply(summon[CanThrow])

But that reasoning breaks down if CanThrow is erased. In that case

def apply(): CanThrow ?=> T

becomes

def apply(): T

The methods have the same signature, so no bridge seems to be needed (nor could we generate one). But if we call apply on Decoder[CanThrow ?=> Int], we still see a Function0 result of apply. That causes the crash.

Possible remedies:

1. Forbid erased context functions: This would apply a (normally useless) penalty to all code that wants to pass static capabilities.
2. Don't apply the context function optimization for erased arguments. This is worse, since it will produce closures instead of just additional unused parameters.
3. Redefine the erasure of erased functions, so that erased A => B is erased to B instead of Function0[B]. This looks like the most promising route but it's a fundamental change to the semantics of erased definitions.
4. Keep a dummy parameter to signify erased function arguments. Still some overhead, but fairly small, and constant.
5. Name mangle methods with a context function result after erasure.

[nicolasstucki]

Here is a self-contained example that only depends on erasedDefinitions

import language.experimental.erasedDefinitions

erased class E

trait Decoder:
  def apply(): E ?=> Int

def decoder: Decoder = new Decoder:
  def apply(): E ?=> Int = 1

@main def run(): Unit =
  decoder.apply().apply(using compiletime.erasedValue)

[nicolasstucki]

Seems that the issue comes from transforming

def apply(): E ?=> Int = 1

into

def apply(): E ?=> Int = (x: E) => apply(using x)
def apply(using E): Int = 1

and then we erase it to

def apply(): Funtion0 = ...
def apply(): Int = ...

Then the JVM gets confused an choose the wrong overload

[nicolasstucki]

We have a related limitation with

object Foo:
  def apply(e: Int): Int = ???
  def apply(): Int ?=> Int = ???

6 |  def apply(): Int ?=> Int = ???
  |      ^
  |Double definition:
  |def apply(e: Int): Int in object Foo at line 5 and
  |def apply(x$0: Int): Int in object Foo at line 6
  |have the same type after erasure.
  |
  |Consider adding a @targetName annotation to one of the conflicting definitions
  |for disambiguation.

[nicolasstucki]

One solution would be to name magle the synthesized optimized accessors.

def foo(): Int ?=> Int = ...

would become

def foo(): Int ?=> Int = (x: Int) ?=> foo$direct$(x)
/*synthetic*/ def foo$direct(x$0: Int): Int = ...

We might also need to add the types of erased arguments for disambiguation. We could use the same name mangling we use to generate names for anonymous givens.