Inlining affects order of execution

[soronpo]

Not completely sure this is a bug, but to me whether a method is inlined or not should not affect the order of execution.

Compiler version

v3.1.0-RC3

Minimized code

var res = ""
trait Bar:
  def +(that: Bar): Bar = new Plus(this, that)
  inline def -(that: Bar): Bar = new Minus(this, that)

class LHS extends Bar {res += "LHS "}
class RHS extends Bar {res += "RHS "}

class Plus(lhs: Bar, rhs: Bar) extends Bar {res += "op"}
class Minus(lhs: Bar, rhs: Bar) extends Bar {res += "op"}

@main def main : Unit =
  val pls = new LHS + new RHS
  val plsRes = res
  res = ""
  val min = new LHS - new RHS
  assert(plsRes == res)

Output

assertion failed

Expectation

No failure. Inlining should not affect the execution order.

[soronpo]

@nicolasstucki What do you think? Is this a bug?

[odersky]

I think that's a bug. Here is the expansion if the - call:

     val min: Minus = 
          {
            val that$proxy1: RHS = new RHS()
            val Bar_this: LHS = new LHS()
            new Minus(Bar_this, that$proxy1)
          }

The definitions of that$proxy1 and Bar_this should be in the reverse order.

[soronpo]

BTW, is there a reason why Bar_this is not given a $ in its name? Like Bar_this$ or Bar_this_$proxy?

[odersky]

@soronpo I think it's because the proxies should be available to meta programming and we want to avoid $ in names because that signals that the name is internal, and user programs use them without stability guarantees. But I am not sure whether meta programming actually uses these proxies.