Fix #5333: Invalid entries in the baseType cache

[smarter]

Provisional types should not have their baseType cached, it may change
as type variables get refined and instantiated.

The seqtype-cycle test had to be adjusted to avoid some missing
reference errors, probably due to the completion order changing.

[dottybot]

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/5343/ to see the changes.

Benchmarks is based on merging with master (0fcbfdb)

[smarter]

@odersky This can be reviewed now, but there's one thing I haven't fully figured out, in:
https://github.com/lampepfl/dotty/blob/7ada2642d53b745b6efbe50aa37bae13d18ccbce/compiler/src/dotty/tools/dotc/core/SymDenotations.scala#L1688-L1689

I assume that the "typeref cannot be a GADT" comment is based on the fact that we check tp.symbol.maybeOwner.isType and gadts on class parameters are not supported currently. However that check alone seems to be insufficient: if caching the base type of a GADT is bad, then caching any type which refers to a GADT could also be bad.
On the other hand, as far as I can tell, the state of the GADT constraints does not influence the result of baseType, therefore it seems that we're safe anyway (and we could potentially cache typerefs even if they come from methods, although that may bloat the cache).

[odersky]

On the other hand, as far as I can tell, the state of the GADT constraints does not influence the result of baseType, therefore it seems that we're safe anyway (and we could potentially cache typerefs even if they come from methods, although that may bloat the cache).

I think that's correct. So we should probably remove the comment since it is irrelevant.

[odersky]

Looks good. Very good analysis, also.

[smarter]

test performance please

[dottybot]

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

[dottybot]

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/5343/ to see the changes.

Benchmarks is based on merging with master (0fcbfdb)