Fix normalization overflow ICEs in monomorphization

[adwinwhite]

Fixes #92004
Fixes #92470
Fixes #95134
Fixes #105275
Fixes #105937
Fixes #117696-2
Fixes #118590
Fixes #122823
Fixes #131342
Fixes #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 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.)
It turns out that checking all Locals 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".

[rustbot]

r? @jieyouxu

rustbot has assigned @jieyouxu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

r? codegen

[jieyouxu]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: fb35892 (fb35892cd06f475414cd254159fed42f93083db6, parent: 05abce5d058db0de3abd10f32f1a442d0f699b30)

[rust-timer]

Finished benchmarking commit (fb35892): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please do so in sufficient writing along with @rustbot label: +perf-regression-triaged. If not, please fix the regressions and do another perf run. If its results are neutral or positive, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	5.9%	[0.3%, 45.5%]	63
Regressions ❌ (secondary)	8.7%	[0.1%, 53.7%]	32
Improvements ✅ (primary)	-0.2%	[-0.3%, -0.1%]	21
Improvements ✅ (secondary)	-1.0%	[-2.9%, -0.1%]	28
All ❌✅ (primary)	4.4%	[-0.3%, 45.5%]	84

Max RSS (memory usage)

Results (primary 9.4%, secondary 6.5%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	9.4%	[1.2%, 31.2%]	57
Regressions ❌ (secondary)	6.5%	[1.4%, 19.0%]	31
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	9.4%	[1.2%, 31.2%]	57

Cycles

Results (primary 11.3%, secondary 16.9%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	11.3%	[1.7%, 51.8%]	44
Regressions ❌ (secondary)	19.5%	[2.5%, 64.2%]	15
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-2.8%	[-3.1%, -2.5%]	2
All ❌✅ (primary)	11.3%	[1.7%, 51.8%]	44

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 467.236s -> 465.852s (-0.30%)
Artifact size: 388.42 MiB -> 388.49 MiB (0.02%)