Inliner can remove side effects from objects

Noticed while discussing #4763, haven’t found in the tracker. Might be a known bug (related to what @allanrenucci noticed recently with constant folding accepting idempotent rather than pure methods), but we should have an issue for this.

EDIT: the issue is that println("object init"); is dropped.

sbt:dotty> repl -Xprint:frontend
object A {
  println("object init");
  inline def x: 1 = { println("x init") ; 1 } //`inline val` requires a val on the rhs
}
scala> object A {
           println("object init");
           inline def x: 1 = { println("x init") ; 1 } //`inline val` requires a val on the rhs
         }

result of rs$line$1 after frontend:
package <empty> {
  final lazy module val rs$line$1: rs$line$1$ = new rs$line$1$()
  final module class rs$line$1$() extends Object() { this: rs$line$1.type =>
    final lazy module val A: A$ = new A$()
    final module class A$() extends Object() { this: A.type =>
      println("object init")
      inline def x: 1.type =
        {
          println("x init")
          1
        }
    }
  }
}
// defined object A

scala>

scala> object B {
           val y = A.x
         }
result of rs$line$2 after frontend:
package <empty> {
  final lazy module val rs$line$2: rs$line$2$ = new rs$line$2$()
  final module class rs$line$2$() extends Object() { this: rs$line$2.type =>
    final lazy module val B: B$ = new B$()
    final module class B$() extends Object() { this: B.type =>
      val y: Int =
        /* inlined from A.x*/
          {
            {
              println("x init")
              1
            }
          }
    }
  }
}
// defined object B

[sjrd]

The inliner’s job is to produce fast code, and it can’t do that if we fix this issue.

I’m sorry but no. The inliner’s primary job is to produce correct code. Under that constraint, it should make it as fast as possible. But disregarding correctness because it’s annoying to produce fast code is a terrible mistake.

If you want to do that, you need to change the language specification to relax the rules of object initialization.

[odersky]

I think we should leave this as is for the moment. The problem is that, without a good purity analysis of objects we end up referring to way too many objects. The inliner’s job is to produce fast code, and it can’t do that if we fix this issue.

I believe the correct approach is to come up with a better purity analysis of objects. #4710 is a start. If we have that, we can switch to isImpure but not before.