Fix #12267: Constraints should not cross phases

[odersky]

Use these changes to compile the stdlib. You need to comment out AnyVal.scala and then
use the following command on community-projects/stdLib213:

scalac -Ydetailed-stats *.scala */*.scala */*/*.scala */*/*/*.scala

What I see is:

Calls to translucentSuperType 53152:

try norm KO -> 53086
try norm OK -> 66

The only computationally relevant part of this are calls to tryMatchAlias

try match alias -> 528

Those calls suceed in 66 cases

try norm OK -> 66

The successful normalizations all return types like this:

try norm OK F[T1] *: scala.Tuple.Map[(T2, T3, T4, T5, T6, T7, T8), F] -> 3

Now it could be that trying the normalizations is costly, or that the normalized types
cause exhaustivity checking to explode. Tht remains to be found out.

[liufengyun]

retest performance with #stdlib please

[dottybot]

performance test scheduled: 3 job(s) in queue, 1 running.

[dottybot]

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/12300-1/ to see the changes.

Benchmarks is based on merging with master (98ecc10)

[odersky]

We might need something like that in the end, but it also hides errors. Before doing this, I wonder whether we could find sources of overflowing constraints and treat them in a more fine-grained manner that does not wait until the end of a phase to remove constraint entries.

[liufengyun]

We might need something like that in the end, but it also hides errors. Before doing this, I wonder whether we could find sources of overflowing constraints and treat them in a more fine-grained manner that does not wait until the end of a phase to remove constraint entries.

Maybe change ctx.constraint.gc() to an assertion instead?

With the following code,

https://github.com/lampepfl/dotty/blob/144069973feb219caf66cb7741f50a75e88cc5e6/compiler/src/dotty/tools/dotc/core/ConstraintHandling.scala#L88-L99

We get constraints like the following in compiling tests/pos/t2619b.scala:

adding constraint B :> AbstractModule to
Constraint(
 uninstantiated variables: B
 constrained types: [B >: ModuleBF.type](prefix: List[B]): List[B]
 bounds:
     B >: ModuleBF.type | ModuleBE.type <: AbstractModule
 ordering:
)
added constraint B :> AbstractModule to
Constraint(
 uninstantiated variables:
 constrained types: [B >: ModuleBF.type](prefix: List[B]): List[B]
 bounds:
     B := AbstractModule
 ordering:
) = true

This will leave the tvar that binds to B uninitialized, thus depends on the constraint for pickling to work correctly.

[odersky]

I think we should do a gc() in the toplevel constraint and should assert that after that the constraint is empty. Right now that's not the case, it seems for several different reasons. I tracked one down to a shortcoming in mergeConstraints but that's not all it seems.

[odersky]

This is now superseded by #12333