Properly deeply normalize in the next solver

[compiler-errors]

Turn deep normalization into a TypeOp. In the old solver, just dispatch to the Normalize type op, but in the new solver call deeply_normalize. I chose to separate it into a different type op b/c some normalization is a no-op in the new solver, so this distinguishes just the normalization we need for correctness.

Then use DeeplyNormalize in the callsites we used to be using a CustomTypeOp (for normalizing known type outlives obligations), and also use it to normalize function args and impl headers in the new solver.

Finally, use it to normalize signatures for WF checks in the new solver as well. This addresses rust-lang/trait-system-refactor-initiative#146.

[compiler-errors]

@bors try @rust-timer queue

[bors]

⌛ Trying commit 0eab7b0 with merge 6fc8fbd...

[bors]

☀️ Try build successful - checks-actions
Build commit: 6fc8fbd (6fc8fbd0fa10d80a9bfdbaec7ce076ac85e4c196)

[rust-timer]

Finished benchmarking commit (6fc8fbd): comparison URL.

Overall result: ❌ regressions - no action needed

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

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

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	0.2%	[0.2%, 0.2%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary -1.1%, secondary -3.4%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.1%	[-1.1%, -1.1%]	1
Improvements ✅ (secondary)	-3.4%	[-3.4%, -3.4%]	1
All ❌✅ (primary)	-1.1%	[-1.1%, -1.1%]	1

Cycles

Results (primary 2.2%, secondary 2.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.2%	[2.2%, 2.2%]	1
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.2%	[2.2%, 2.2%]	1

Binary size

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

Bootstrap: 771.158s -> 769.467s (-0.22%)
Artifact size: 325.82 MiB -> 325.81 MiB (-0.00%)

[lcnr]

why does this ICE now?

[compiler-errors]

Because we now fail to normalize but otherwise do not emit an error message.

This should be fixed by my PR which fixes recursive coroutine detection.

[compiler-errors]

Fixed by #136073, which I've stacked underneath these changes. Blocked on that PR for now, which is waiting on bors.

[bors]

☔ The latest upstream changes (presumably #136203) made this pull request unmergeable. Please resolve the merge conflicts.

[lcnr]

r=me once it's unblocked

[bors]

☔ The latest upstream changes (presumably #134824) made this pull request unmergeable. Please resolve the merge conflicts.

[lcnr]

please add a next-solver revision to tests/ui/implied-bounds/normalization.rs