Anonymous functions defined in anonymous classes are emitted on containing object instead of being emitted on anonymous class

This may be expected behavior / an optimization but I wanted to open an issue to determine if it’s intended or not. This behavior resulted in a bug in FS2: https://github.com/typelevel/fs2/issues/2623

Compiler version

3.0.2

Minimized code

trait Foo {
  def foo(x: Option[Int]): Option[Int]
}

object Bar {
  def mk = new Foo {
    def foo(x: Option[Int]) = x.map(_ + 1)
  }
}

Output

➜  javap -c -cp . Bar\$
Compiled from "foo.scala"
public final class Bar$ implements java.io.Serializable {
  public static final Bar$ MODULE$;

  public static {};
    Code:
       0: new           #2                  // class Bar$
       3: dup
       4: invokespecial #18                 // Method "<init>":()V
       7: putstatic     #20                 // Field MODULE$:LBar$;
      10: return

  public Foo mk();
    Code:
       0: new           #9                  // class Bar$$anon$1
       3: dup
       4: invokespecial #30                 // Method Bar$$anon$1."<init>":()V
       7: areturn

  public static final int Bar$$anon$1$$_$foo$$anonfun$1(int);
    Code:
       0: iload_0
       1: iconst_1
       2: iadd
       3: ireturn
}

Note the final member: public static final int Bar$$anon$1$$_$foo$$anonfun$1(int);

Expectation

javap -c -cp . Bar\$
Compiled from "foo.scala"
public final class Bar$ {
  public static final Bar$ MODULE$;

  public static {};
    Code:
       0: new           #2                  // class Bar$
       3: dup
       4: invokespecial #14                 // Method "<init>":()V
       7: putstatic     #16                 // Field MODULE$:LBar$;
      10: return

  public Foo mk();
    Code:
       0: new           #7                  // class Bar$$anon$1
       3: dup
       4: invokespecial #19                 // Method Bar$$anon$1."<init>":()V
       7: areturn
}

[smarter]

I don’t have any specific idea of what to do here but:

Scala 3.0, 3.1 and 3.2 would need to be supported

I think it’s better to dedicate resources towards improved support for future compiler versions rather than trying to support obsolete versions at all cost. We’re releasing new minor releases at a rapid pace and doing everything we can to make it easy for people to upgrade. This should be good news for tooling authors since they can fix things in the compiler (as might need to be done here?) and have these fixes delivered to users quickly rather than maintaining workarounds forever.

However, the debugger is broken for Scala 3, and precisely because of this change.

Metals is also working on having a debugger that supports expression evaluation with Scala 3, this sounds like an area where you could collaborate.

[vasilmkd]

Thanks for the input @smarter.