Regression: Lazy val in local mixin trait is not memoized

[tschuchortdev]

Compiler version

Reproduced on 3.7.1, 3.7.0, 3.3.6 LTS. Works correctly on 2.13.

Minimized code

//> using scala 3.7.0
//> using options -Wall -Werror -Wsafe-init

trait Interface {
  def value: String
}

var baseInitialized = 0
class BaseClass extends Interface {
  override def value: String = {
    baseInitialized += 1
    "hello"
  }
}

def doIt() = {

var mixin1Initialized = 0
trait Mixin1 extends Interface {
  private lazy val value_lazyval: String = {
    mixin1Initialized += 1
    super.value ++ " mixin1"
  }
  abstract override def value: String = this.value_lazyval
}

val derived = new BaseClass with Mixin1

println(derived.value)
println(mixin1Initialized == 1)

derived.value: Unit
println(mixin1Initialized == 1)
  
}

doIt()

https://scastie.scala-lang.org/jiipi0fQS7WH1lPdPP7bHw

Output

hello mixin1
true
false

should be

hello mixin1
true
true

Expectation

The value_lazyval should be memoized but the body appears to get executed again on each invocation. Interestingly, this only happens if the mixin trait is a local class (comment out the doIt function to test for yourself). The behaviour here is very insidious and a regression compared to Scala 2.13, where above snippet works as expected.

[som-snytt]

After lambdalift, derived.value calls the mixin value(IntRef) which calls the mixin value_lazyval(Intref) and not the derived.value_lazyval or lazy def C$_$Mixin1$$value_lazyval(): String which is not an override.

derived.value_lazyval calls the lazyINIT which correctly calls the mixin value_lazyval(Intref).

On Scala 2, the IntRef is supplied to the constructor instead of the methods, so there is no signature mismatch.

Probably derived.value_lazyval should be an override with the amended signature.

It's not specific to lazy val, as any override (of the trait method in an anonymous concrete class) demonstrates the issue:

class C {
  def f = {
    var i = 42
    trait M {
      def m() = {
        println(s"em & m")
        i += 1
      }
      lazy val v: Int = 27 + i
    }
    class K extends M {
      override def m() = {
        println(s"k m")
        super.m()
      }
    }
    val k = new K
    val x = new M {
      override def m() = {
        println(s"anon m")
        super.m()
      }
    }
    k.m()
    x.m()
    k.v + x.v
  }
}

object Test extends App {
  println {
    new C().f
  }
}

In f, it correctly uses k.m() (the override), but incorrectly uses x.m(i) (not overridden); and for the lazy val, f incorrectly uses v(i) in both cases (anonymous or named K), so the behavior changes for lazy.

My naive guess is that subclasses of M should override m(i) and define def m() = m(this.i).

[som-snytt]

My other idea was to emit proxy accessors instead, so that trait M has protected def i$4: IntRef (with a suitably mangled name) which is implemented in the concrete class. Then method signatures would remain unmolested. (Currently the class must have the field, so this amounts to making it available to the trait via a special accessor, similar to super accessors.)

First I'll try adding the forwarder, which is override def m(@unused i: IntRef) = m(), where there is an existing override, and the forwarder ignores the proxy parameters.