Guard against opaques crashing the compiler

[dwijnand]

Fixes #19434

[odersky]

One possibility would be to merge ElimOpaque with erasure. It's a tiny phase. I am not sure anything between ElimOpaque and Erasure depends on the fact that opaque aliases are now aliases. So far no phase declares that it needs to run after ElimOpaque but that's of course no guarantee that there are no dependencies.

[dwijnand]

I could see that fixing this case, seeing as the code branch is run in preErasureCtx.

[dwijnand]

How do we deal with SeqLiterals and opaque types? With merging ElimOpaque into Erasure, we now box opaque primitives. And I can't find a way to phase travel and get classSymbol to give me the Int symbol.

[odersky]

Hmm. Maybe we have to leave ElimOpaque where it is since it seems to upset quite a few assumptions afterwards. We should document in the relevant phases that they have to run after ElimOpaque.

That means that match type reduction has to cope with this somehow. One trick we could play is to refuse to normalize match types after ElimOpaque. Instead, time-travel to the ElimOpaque phase and do the reduction there. Or else treat normal aliases like opaque aliases, if the symbol has Opaque set before ElimOpaque. Not sure whether the second one is safe, though.

[dwijnand]

Instead, time-travel to the ElimOpaque phase and do the reduction there. Or else treat normal aliases like opaque aliases, if the symbol has Opaque set before ElimOpaque. Not sure whether the second one is safe, though.

I didn't quite understand what you meant here. Could you explain again what you think we should try? Currently I'm just phase travelling to typer.

[sjrd]

My take on that idea is that we could try an ElimMatchTypes before ElimOpaues. It would replace every match type that reduces to its reduction, and for the others leave them as shells that only keep the upper bound and can never further reduce.

I'm not sure whether that's sound TBH.

[dwijnand]

Can't make that work. It fails Ycheck.