Fix #15494: Handle non-specialized functions in EtaReduce.

[sjrd]

In Scala.js, function specialization is disabled. This means that non-specialized functions can reach EtaReduce. Previously, it did not handle the shape of right-hand-side for non-specialized functions returning primitives. We fix the issue by handling those, like we already handled .asInstanceOfs.

How I fixed it

First, I took the reproduction from the issue and put it in sandbox/scalajs/src/hello.scala. I verified that I could reproduce with

> sjsSandbox/run

Next, I looked at the Scala.js IR produced for this code:

> sjsSandbox/scalajsp Thunk$

showed nothing wrong, but

> sjsSandbox/scalajsp hello$package$

showed, sure enough, an extra wrapping when calling asFunction0 for f2 and f3, which is not present for f1:

  def Test;V() {
    val i: scala.runtime.IntRef = scala.runtime.IntRef::create;I;Lscala.runtime.IntRef(0);
    val f1: scala.Function0 = <redacted>;
    if ((!(mod:hello.Thunk$.asFunction0;Lscala.Function0;Lscala.Function0(f1) === f1))) {
      mod:scala.runtime.Scala3RunTime$.assertFailed;E()
    };
    val f2: scala.Function0 = <redacted>;
    if ((!(mod:hello.Thunk$.asFunction0;Lscala.Function0;Lscala.Function0(new scala.scalajs.runtime.AnonFunction0().<init>;Lscala.scalajs.js.Function0;V((arrow-lambda<this$3{this}: hello.hello$package$ = this, f2$2{f2}: scala.Function0 = f2>(): any = {
      this$3.hello.hello$package$::private::Test$$anonfun$1;Lscala.Function0;I(f2$2)
    }))) === f2))) {
      mod:scala.runtime.Scala3RunTime$.assertFailed;E()
    };
    val f3: scala.Function0 = <redacted>;
    if ((!(mod:hello.Thunk$.asFunction0;Lscala.Function0;Lscala.Function0(new scala.scalajs.runtime.AnonFunction0().<init>;Lscala.scalajs.js.Function0;V((arrow-lambda<this$5{this}: hello.hello$package$ = this, f3$2{f3}: scala.Function0 = f3>(): any = {
      this$5.hello.hello$package$::private::Test$$anonfun$adapted$1;Lscala.Function0;Ljava.lang.Object(f3$2)
    }))) === f3))) {
      mod:scala.runtime.Scala3RunTime$.assertFailed;E()
    }
  }

Now I needed to diagnose what phase within the compiler caused the issue. I do that with

> set sjsSandbox / scalacOptions += "-Xprint:flatten"
> sjsSandbox/compile

flatten is always a good first candidate when working on Scala.js issues, as it shows the dotc trees right before the back-end.

flatten shows that the wrappings are already there, so the issue must come earlier. There's not supposed to be major differences in transformations in earlier phases for Scala.js versus Scala/JVM, especially when no Scala.js-specific code is involved.

So I started investigating the difference in -Xprint between Scala/JVM and Scala.js for the same snippet.

I reached the conclusion that the group of etaReduce received as input something worse on Scala.js than Scala/JVM. And for good reason: the input on Scala/JVM uses specialized function types, which don't exist on Scala.js.

I then tried reproducing on Scala/JVM by manually deactivating the SpecializeFunctions phase. Sure enough, the issue was triggered.

From there, it was a matter of looking at the shape of trees received by EtaReduce when SpecializeFunctions is disabled, and adding cases in EtaReduce to handle those shapes.

[Kordyjan]

As it is a regression from 3.1.2, I think we should backport it to 3.2.0.

[sjrd]

What's the procedure for that? Do I retarget this PR to release-3.2.0? Or do we first review and merge in main before cherry-picking to release-3.2.0?

[odersky]

What's the procedure for that? Do I retarget this PR to release-3.2.0? Or do we first review and merge in main before cherry-picking to release-3.2.0?

We merge to main and then backport.

[odersky]

Nice explanation of the fix!