Init check: Early Promotion of fields

[natsukagami]

• New checks for Promote(pot, outer) effect.
• The old checking rule (Promote(pot, outer) <= Promote(outer)) is now used as a quick check (canDirectlyPromote), before the newer, more costly check is run.

---

This change is 

[liufengyun]

This will lead to infinite loops. The following might be a test case:

class A {
  val a = f
  def f: A = f
  class B(x: Int)

  println(new a.B(5))
  val n = 10
}

[natsukagami]

Mitigating this with a visited set. I think it's easier to just set a maximum recursion depth though, because this is only a speed-up measure most of the time...

[liufengyun]

Yes, you can play with it and see which works better for the tests we have.

[liufengyun]

Thanks for the good work.

We still need to

• figure out the failures in CI
• avoid expensive analysis of early promotion so that community build can finish fast

BTW: it's better to rebase against master than merging master to this PR.

[liufengyun]

Yes, you can play with it and see which works better for the tests we have.

[liufengyun]

The community build does not finish within 3 hours. We need to find a way to avoid "expensive" analysis. A budget for early promotion?

[natsukagami]

The following program will take some time to type-check:

class A {
  def v: A = new A {
    def get_b: A = 
      v1
      v2
      // v3
      v
  }
  def v1 = v
  def v2 = v
  // def v3 = v
  print(v)
}

The time taken to type-check seems to grow exponentially compared to the number of methods (if I uncommented v3, it runs substantially slower). This is due to nesting of Warm not being re-used, since v creates a new anonymous subclass every time we run into a check.

The above problem is super-evident in the scalax.rules.Rule class of scalap, where almost every defined operator ends up creating an anonymous class.

[liufengyun]

Nice minimization @natsukagami 👍 The program does not seem to be complex, there might be a big optimization opportunity hidden there.

[natsukagami]

@liufengyun Turns out the long running time was caused by the cache bug fixed in #11385 #12055 :)
EDIT: Mentioned the wrong PR...

[liufengyun]

@liufengyun Turns out the long running time was caused by the cache bug fixed in #11385 :)

Thanks @natsukagami, great to know. I did expect #12055 to improve performance but didn't know it causes exponential behavior.

[liufengyun]

LGTM, thanks @natsukagami 🎉