Detect cycle errors hidden by opaques during monomorphization

[compiler-errors]

Opaque types may reveal to projections, which themselves normalize to opaques. We don't currently normalize when checking that opaques are cyclical, and we may also not know that the opaque is cyclical until monomorphization (see tests/ui/type-alias-impl-trait/mututally-recursive-overflow.rs).

Detect cycle errors in normalize_projection_ty and report a fatal overflow (in the old solver). Luckily, this is already detected as a fatal overflow in the new solver.

Fixes #112047

[rustbot]

r? @davidtwco

(rustbot has picked a reviewer for you, use r? to override)

[compiler-errors]

🤦

@rustbot author

[compiler-errors]

@rustbot ready

This rustdoc-only hack makes me sad, but it does fix a strange TAIT/RPITIT-only post-mono error in a more graceful way than ICEing. Maybe @oli-obk can leave some thoughts too.

[oli-obk]

Does it do that for code that passes rustc? We are allowed to cause new errors in rustdoc if the code also wouldn't compile in rustc.

[oli-obk]

a more graceful way than ICEing

ah, that's the issue. hmm.. does rustdoc unwrap something instead of reporting an error? or where is the ICE coming from?

[compiler-errors]

We are allowed to cause new errors in rustdoc if the code also wouldn't compile in rustc

Well, the problem is that we need to do HIR analysis to make sure we don't have things like malformed and overlapping impl blocks too. These are probably not what we want to "fix" in rustdoc, since we compile rustdoc with all features enabled and stuff?

We also would need to check all type aliases as well-formed too, which we don't even do in rustc yet.

does rustdoc unwrap something instead of reporting an error? or where is the ICE coming from?

The ICE is coming from a failed projection in the QueryNormalizer.

What happens is that we hit a cycle here:

rust/compiler/rustc_trait_selection/src/traits/project.rs

Lines 1193 to 1196 in 0692db1

	Err(ProjectionCacheEntry::Recur) => {
	debug!("recur cache");
	return Err(InProgress);
	}

Which means we treat the projection as ambiguous and emit a projection goal with an infer var on the RHS. That causes us to hit this assertion with debug assertions enabled:

rust/compiler/rustc_traits/src/normalize_erasing_regions.rs

Line 50 in 0692db1

debug_assert!(!erased.has_infer(), "{erased:?}");

Or just errors out with NoSolution, which causes normalize_erasing_regions to ICE.

[oli-obk]

Ah... yea that makes sense sadly.

Tho Rustdoc is moving towards doing wf checks in the future, so this will get cleaned up

[oli-obk]

@bors r+

[bors]

📌 Commit 8fbd78c has been approved by oli-obk

It is now in the queue for this repository.