Refine parameter adaptation logic for arrays

[bracevac]

Fixes #23179

Since JDK 9, argument checks for LambdaMetaFactory have become stricter. Which is to say that its JDK 8 version was too lax.

We apply adaptation now in case the samType is an array, but the implType is not.

[sjrd]

This seems misguided to me. Why AnyRef but not any of its subtypes? Also, this is not supported by spec text, whether from the Scala 2 or Scala 3 spec.

Changes to erasure are extremely risky, because they basically break tasty and binary compatibility every time. They need a very strong justification. Typically, only fixing unsoundness is a good enough reason to do this.

[bracevac]

Scala 2 certainly erases this array type to Object[]. What should be the general rule?

Edit: Hmm it does not, at least judging by -Xprint:erasure. However in the resulting bytecode, the two relevant arguments to altMetaFactory are consistently array types, whereas in Scala 3 the second one ends up being Object.

BootstrapMethods:
  0: #38 REF_invokeStatic java/lang/invoke/LambdaMetafactory.altMetafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
    Method arguments:
      #26 ([Ljava/lang/Object;)Ljava/lang/Object;
      #30 REF_invokeStatic Test$.$anonfun$new$1$adapted:([Ljava/lang/Object;)Ljava/lang/Object;
      #26 ([Ljava/lang/Object;)Ljava/lang/Object;
      #31 0

[bracevac]

If we do not want to mess with erasure, could we just uniformly use the erased SAM methodtype for the implementation method type as well in the emitted bytecode? Would this always be safe for a type-correct source program?

[sjrd]

Probably, but we would need to do that at the backend level. Basically consider it a bridge method, or an $adapted something something. The extracted private def likely cannot be altered to take a different parameter type.

[sjrd]

The new approach seems reasonable.

It might need similar changes in ExpandSAMs for Scala SAM types that don't translate to target SAM types.

[sjrd]

Shouldn't there be the reverse order as well ((_, defn.ArrayOf(_)))? Like if the SAM takes an Array[T] where T <: AnyRef but the lambda is specialized to T = String, for example?

[bracevac]

I'm unable to construct such a reversed example that will be accepted by the compiler.

[lrytz]

Do we need something similar for the result type (resultAdaptationNeeded)?

[bracevac]

Not sure, I also fail here to construct an example that would cause a run time crash (which is of course weak evidence).

[bracevac]

The new approach seems reasonable.

It might need similar changes in ExpandSAMs for Scala SAM types that don't translate to target SAM types.

I tried constructing each of the five cases in the comment at the top of ExpandSAMs, but those were either rejected or did not crash at run time.

[lrytz]

It might be worth including the other combinations in the test case as regression tests.

[bracevac]

This solution doesn't appear to work for ScalaJS, I'll need to dig deeper.

[bracevac]

@sjrd @lrytz for scalajs, I needed to tweak ExpandSAMs next to the JVM-specific tweak in Erasure. The tests all pass now. I've also added the requested regression tests.

PS: The failing stdlib test is CC-related and not due to this PR. It also fails on main.

[sjrd]

What if it's hidden behind a PolyType? Or in a second term param list?

[bracevac]

Do you have a concrete example in mind? Those cases do not qualify as SAMs afaik.
I've added more run tests that involve multiple parameters and a generic return type on the trait.

For generics on the method, the compiler rejects both of these:

trait PolyA { def f[T](a: Array[AnyRef]): T }

object Test {
  def gPoly(a: PolyA) = a.f[Int](Array.empty[AnyRef])

  def main(args: Array[String]): Unit = {
    gPoly([T] => (x: Array[? >: AnyRef]) => x.length.asInstanceOf[T]) // error

    gPoly(new PolyA { // error
      def f[T](x: Array[? >: AnyRef]): T = x.length.asInstanceOf[T]
    })
  }
}

Same goes for curried argument lists:

trait CurriedA { def f(a: Array[AnyRef])(b: Int): Any }

object Test {
  def gCurried(a: CurriedA) = a.f(Array.empty[AnyRef])(42)

  def main(args: Array[String]): Unit = {
    gCurried((x: Array[AnyRef]) => (n: Int) => x.headOption) // error
  }
}

Scala 2 rejects these as well (modulo the polymorphic lambda syntax of course).

[sjrd]

Those cases do not qualify as SAMs afaik.

Right. I missed that. Seems all good.

[WojciechMazur]

Should this change be backported to 3.8.0? It seems to be that it might be useful, since it's now compiled with JDK 17 so potentially might be affected.
I guess that changes here should also help with fixing #24573 which this time was affected by result type checks

[bracevac]

Yes, any JDK newer than 8 would result in a runtime failure for the kind of example this PR addresses.