Fix normalization overflow ICEs in monomorphization Fixes rust-lang/rust#92004 Fixes rust-lang/rust#92470 Fixes rust-lang/rust#95134 Fixes rust-lang/rust#105275 Fixes rust-lang/rust#105937 Fixes rust-lang/rust#117696-2 Fixes rust-lang/rust#118590 Fixes rust-lang/rust#122823 Fixes rust-lang/rust#131342 Fixes rust-lang/rust#139659 ## Analysis: The causes of these issues are similar. They contain generic recursive functions that can be instantiated with different args infinitely at monomorphization stage. Ideally this should be caught by the [`check_recursion_limit`](https://github.com/rust-lang/rust/blob/c0bb3b98bb7aac24a37635e5d36d961e0b14f435/compiler/rustc_monomorphize/src/collector.rs#L468) function. The reality is that normalization can reach recursion limit earlier than monomorphization's check because they calculate depths in different ways. Since normalization is called everywhere, ICEs appear in different locations. ## Fix: If we abort on overflow with `TypingMode::PostAnalysis` in the trait solver, it would also catch these errors. The main challenge is providing good diagnostics for them. So it's quite natural to put the check right before these normalization happening. I first tried to check the whole MIR body's normalization and `references_error`. (As elaborate_drop handles normalization failure by [returning `ty::Error`](https://github.com/rust-lang/rust/blob/c0bb3b98bb7aac24a37635e5d36d961e0b14f435/compiler/rustc_mir_transform/src/elaborate_drop.rs#L514-L519).) It turns out that checking all `Local`s seems sufficient. These types are gonna be normalized anyway. So with cache, these checks shouldn't be expensive. This fixes these ICEs for both the next and old solver, though I'm not sure the change I made to the old solver is proper. Its overflow handling looks convoluted thus I didn't try to fix it more "upstream".
This is serves as a collection of crashes so that accidental ICE fixes are tracked. This was formally done at https://github.com/rust-lang/glacier but doing it inside the rustc testsuite is more convenient.
It is imperative that a test in the suite causes an internal compiler error/panic or makes rustc crash in some other way. A test will "pass" if rustc exits with something other than 1 or 0.
When adding crashes from https://github.com/rust-lang/rust/issues, the
issue number should be noted in the file name (12345.rs should suffice)
and also inside the file via //@ known-bug #4321 if possible.
If you happen to fix one of the crashes, please move it to a fitting
subdirectory in tests/ui and give it a meaningful name.
Also please add a doc comment at the top of the file explaining why
this test exists. :)
Adding
Fixes #NNNNN
Fixes #MMMMM
to the description of your pull request will ensure the
corresponding tickets will be closed automatically upon merge.
The ticket ids can be found in the file name or the known-bug annotation
inside the testfile.
Please do not re-report any crashes that you find here!