Add `inline` changes semantics

Compiler version

master

Minimized code

class A(val x: Int):
  class X:
    inline def foo() = A.this.foo()           // remove inline changes semantics

  private def foo(): Unit = println(x)

class B extends A(20):
  val a = new A(10)
  val y: Y = new Y

  class Y extends a.X

class C:
  var b = new B
  b.y.foo()  // should print 10, but prints 20

@main
def test = new C()

Output

20

Expectation

It should print 10, but it prints 20.

Initial Diagnosis

The problem seems to be related to the encoding of outer-select in inlining. The example above seems to suggest that hops alone is ambiguous.

[nicolasstucki]

When we inline the code we probably need to find the references to the outer this references and adapt them to the inline binding in the scope where they are inlined. Use -Xprint:inlining.

I see we get this

class C() extends Object() {
    var b: B = new B()
    def b_=(x$1: B): Unit = ()
    {
      val X_this: (B#y : B#Y) = this.b.y
      val A_this: (B#a : A) = X_this.1_<outer> // suspicious reference
      A_this.inline$foo():Unit
    }
  }

We should first try to:

• Minimize the example
• Figure out what should be on the RHS of A_this, or in general what code should be generated

[dwijnand]

The PR seems viable. I was coming back to this to ask: seeing b isn’t stable, is inlining off of a non-stable path meant to work? I only noticed because you can’t call new on it (val y: Y = new b.Y).