Fix #12408: Parameterized classes should be applied for prefix inference

[liufengyun]

Fix #12408: Parameterized classes should be applied for prefix inference

[dwijnand]

There already was a recursive this(tref) call, so why weren't parameterized classes inferring their prefix already?

[liufengyun]

There already was a recursive this(tref) call, so why weren't parameterized classes inferring their prefix already?

The recursive this(tref) will substitute prefix with type variables, the actual inference happens later. The issue here is that before this change, the bound of the type variable has the wrong kind -- thus the subtyping A' <: P is false. This disqualifies A/B/C as valid children of P. Consequently, P decomposes to empty thus the warning about null.

[dwijnand]

I feel less sure about wiping out the bounds: if X were class X[T <: Foo] then when X.this.A is replaced with Y.A then I take it Y <: X[?] but I feel it should be Y <: X[? <: Foo]...

But nothing seems to be broken in CI validation.

[liufengyun]

I feel less sure about wiping out the bounds: if X were class X[T <: Foo] then when X.this.A is replaced with Y.A then I take it Y <: X[?] but I feel it should be Y <: X[? <: Foo]...

Good point. Here we assume the user writing reasonable code such that the bounds don't affect the prefix. Otherwise, many things would become subtle (typeclass derivation, match types, etc.). We can revisit the assumption if a valid use case does appear.

[dwijnand]

We can revisit the assumption if a valid use case does appear.

Sounds good to me.