Generate anonymous class for SAMs defining narrowed overrides

[WojciechMazur]

Fixes #15402

Invocation of method on SAM using overridden narrowed method was leading to java.lang.AbstractMethodError: Receiver class i15402$package$$$Lambda$1/0x0000000100085840 does not define or inherit an implementation of the resolved method X in Y. . To mitigate this issue we make sure that for each SAM which defines a narrowed member override we would generate an anonymous class.

[smarter]

I don't think that's enough, the decls of a types don't include inherited member, so what happens in the test case if I have trait Foo2 extends Foo and I try to make a SAM of Foo2? At the same time, the check seems too broad: we only need to worry about the type of the single abstract method we're implementing, for all other methods in the trait, it's fine if they're covariantly overridden.
Maybe try to have a look at what logic Scala 2 uses (probably in Uncurry?) and try to match that?

By the way, since Jave also has covariant overrides, the JVM does have some support for generating bridges in lambdas for this usecase (grep for bridge in https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/MethodHandles.html), and both Scala 2 and Scala 3 actually have code to deal with that, so I'm not sure why it's not being used in this example for Scala 2:

• https://github.com/scala/scala/blob/dd47c68522c3e8e92e8342649e999762e829d1ac/src/compiler/scala/tools/nsc/backend/jvm/BCodeBodyBuilder.scala#L1494-L1501
• https://github.com/lampepfl/dotty/blob/004a2fd0095a5d219271eaaf1360fe5be3d2becc/compiler/src/dotty/tools/backend/jvm/BCodeBodyBuilder.scala#L1727-L1740

[WojciechMazur]

@smarter from what I've observed the diverged behavior starts when checking if the SAM can be compiled to pure interface. In Scala 2 it involves checking if SAM has no primary constructor https://github.com/scala/scala/blob/92f1948cb746b1afbf71c90bde0f20e577b8a9fd/src/compiler/scala/tools/nsc/transform/Erasure.scala#L1418-L1421

In Scala 3 however, we use NoInits for that kind of check. The problem is that the primary constructor always exits in both (Foo and Foo2) and are marked as no inits.
https://github.com/WojciechMazur/dotty/blob/f3b66e148efeed4c11958c35974e52dffbf93744/compiler/src/dotty/tools/dotc/config/JavaPlatform.scala#L41-L46

I've seen a 1 major difference between Scala 2 and 3 in this logic. If we would try to use other SAMs, in a similar way eg:

trait SimpleNamed:
  def foo(x: String): String

trait Foo3 extends SimpleNamed

then both of them would have flags set to PureInterface in Dotty and no primary constructor in Scala 2 , which would allow using it in LambdaMetaFactory. Primary constructor is always present in Dotty
On the other hand, Foo from the original snippet would have a primary constructor in Scala 2 (because of abstract def me: Named) which forces expanding closure to an anonymous class, while in Scala 3 it is a NoInitsTrait (not a PureInterface) which leads to the evaluation of isSam test to true.

Do you think isSam test should be more strict and allow only for NoInitsInterfaces instead of NoInitsTrait for SAM class symbol (it fixes Foo case) and also require NoInitsInterface or recursive isSam test in all directly inherited traits instead of NoInits (to fix Foo2 case)?

I'm not sure how would such a change be binary compatible with previous Scala version and is it not too strict, however it looks like Scala 2 generate anonymous class wrapper for all traits and uses LambdaFactory only for interfaces.

[nicolasstucki]

To fix the MiMa tests, we should be able to re-run the tests now that #15457 is merged.

[WojciechMazur]

Replaced with #15551