Rewrite resolveThis in global init checker

[EnzeXing]

This PR resolves bugs in the redesigned global initialization checker; specifically, it now correctly resolves the value of parent.this in a child class, and removes the assertions that fail in community build projects

[test_scala2_library_tasty]

[olhotak]

Should we keep an assertion that isRefSet || isEnvSet?

[olhotak]

Is it possible that target could be a parent class of an outer class?

[olhotak]

Here's an example of a ScopeSet that can have both classes and methods.

class A {
  var x = 42
  def change = (x = 44)
  class B {
    val i = 5
    def fooz = A.this.x // if this is an instance of class C, does A.this resolve to the C outer or to the B outer ???
    def fooz2 = A.this.x
    class D {
       def bar = fooz
       def bar2 = fooz2
    }
  }
}
class AA extends A {
  def foo = {
    //val y = 43
    val a = if(*) new A else new AAA
    class C /*outer AA*/ extends a.B /*outer A or AAA*/ {
       override val i = 6
       override def fooz2 = x
    }
    val bb: B = if(false) new a.B else new C
    val d =  new bb.D
    d.bar   // reads AA.x
    d.bar2 // reads AA.x
    }
}

d --outer-> {B or C} --outer-> {A or foo} --outer --> {A}
d.bar, looking for x
reach {A or foo}
A has x, foo doesn't
do I continue searching the outer of foo ???

[EnzeXing]

@olhotak @liufengyun I have added two rather complex tests, feel free to run them with scala-cli.
With regard to multiple-outers.scala, here are my explanations:

1. When accessing a field, the access chain from the enclosing class of the select expression to the enclosing class of the field is composed with two kinds of edges: $\overrightarrow{\text{outer}}$ and $\overrightarrow{\text{parent}}$. $\overrightarrow{\text{outer}}$ corresponds to a call of resolveThis, and $\overrightarrow{\text{parent}}$ relates to how we handle inherited fields
2. In an access chain, $\overrightarrow{\text{outer}}$ can be followed by $\overrightarrow{\text{parent}}$, but $\overrightarrow{\text{parent}}$ cannot be followed by $\overrightarrow{\text{outer}}$. Example:

class A {
  val field_a = 5
  def bar(): Int = A.this.field_a
}

class B extends A {
  val field_b = field_a
  class C {
    val field_c = bar() // expands to B.this.bar()
    val field_c2 = field_a // C --> outer B --> parent A
  }
}

object O:
  val b = new B
  class D extends b.C {
    val field_d = field_b // D --> parent C --> outer B (invalid)
    // error: Not found: field_b
  }
  val d = new D

3. At a particular step, if both two kinds of edges are valid, compiler issues an error for ambiguous access. Example:

class A {
  val x = 5
}

class B {
  val x = 6
  class C extends A {
    val f = x // error: Reference to x is ambiguous.
  }
}

[EnzeXing]

The second test anon-class.scala is a tricky one, since it has the edge B $\overrightarrow{outer}$ B with the same dynamic class, so calling resolveThis cannot terminate. Maybe the potential solution is to stop when the combined outer set reaches a fixed point

[liufengyun]

The second test anon-class.scala is a tricky one, since it has the edge B o u t e r → B with the same dynamic class, so calling resolveThis cannot terminate. Maybe the potential solution is to stop when the combined outer set reaches a fixed point

It's not clear why resolveThis should be a problem. I see the last PR changed resolveThis by removing the parameter klass: that is problematic semantically and I think it also caused the loop.

The following comment might help:

scala3/compiler/src/dotty/tools/dotc/transform/init/Semantic.scala

Lines 1207 to 1216 in 0be2091

	* Note that `klass` might be a super class of the object referred by `thisV`.
	* The parameter `klass` is needed for `this` resolution. Consider the following code:
	*
	* class A {
	* A.this
	* class B extends A { A.this }
	* }
	*
	* As can be seen above, the meaning of the expression `A.this` depends on where
	* it is located.

[olhotak]

[test_scala2_library_tasty]

[liufengyun]

LGTM, I only have a few minor comments for consideration.

[liufengyun]

Is it possible for scope in Config to be Ref? The same question for Fun.

These are the only place where the type Scope appears. If we can remove one concept, that would be nice (Occam's razor).

[liufengyun]

Minor: regarding the name LocalEnv, maybe we can use something like EnvAddr or EnvRef?

[EnzeXing]

Is it possible for scope in Config to be Ref? The same question for Fun.

These are the only place where the type Scope appears. If we can remove one concept, that would be nice (Occam's razor).

When evaluating the field initializers, the scope in Config would be Ref; the same holds when creating a Fun in a field initializer

[EnzeXing]

Minor: regarding the name LocalEnv, maybe we can use something like EnvAddr or EnvRef?

Has renamed it to EnvRef

[liufengyun]

When evaluating the field initializers, the scope in Config would be Ref; the same holds when creating a Fun in a field initializer

Thanks for explaining. In later PRs, we can consider creating an empty Env with the primary constructor for evaluating field initializers if that works.

[liufengyun]

Minor (for future): Given that Var and Val have same logic, we can consider generalize a little the code.

[EnzeXing]

Does anyone know why Test CLI Launchers failed? Should I push again?

[olhotak]

LGTM now. @EnzeXing we can merge when you think you're done with @liufengyun 's minor comments.

[olhotak]

Does anyone know why Test CLI Launchers failed? Should I push again?

It timed out. I restarted the job.

[EnzeXing]

I've addressed Fengyun's comments, and I think it's ready to be merged