Store GADT constraints until PostTyper

[abgruszecki]

In some cases, the attachment can get dropped. We have a lot of such cases. Most seem to happen for tuple patterns.

[odersky]

test performance please

[dottybot]

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

[odersky]

I am wary that this could give bad memory leaks. GADT constraints can be large.

Why do we need GADT constraints in PostTyper? The PR does not explain, nor does the code.

[abgruszecki]

@odersky there's a serious problem - type application that needs GADT constraints simply doesn't work. #12226 is one example. Another one is that without this PR we get an error on this line: https://github.com/lampepfl/dotty/pull/12258/files#diff-953aaf705b431c6945ad2bd63ce89e017169f7373c45f9c40f265f4d11705a81R11.

The reason why type application doesn't work is that we check it in PostTyper, when we already forgot the GADT constraints. I tried moving the checks to Typer, but it seems like there's no clean way to do that, for instance b/c when we exit typedTypeApply, the type arguments may still be variables. So that means we should either re-infer the constraints in PostTyper, or store and extract them. Of those two solutions, storing the constraints is by far the cleanest and the most future-proof. EDIT: also, note that we actually remove the constraints in PostTyper.

If we ever get problems because of too many GADT constraints, we could simply infer less of them. It's always sound to infer less GADT constraints. IIRC, GHC also stores its GADT constraints, and won't record constraints past some threshold.

[dottybot]

Performance test finished successfully:

Visit https://dotty-bench2.epfl.ch/12258/ to see the changes.

Benchmarks is based on merging with master (2d2038e)

[odersky]

OK. I'd just add a comment explaining why we need to attach GADT constraints