rustdoc: skip blanket impls on recursive types

[im-lunex]

When a type contains itself through its fields (e.g. struct A(B<A>)),
evaluating blanket impl obligations on it can hang or take exponential
time. Skip blanket impl synthesis entirely for such types.

Adds a TypeVisitor that walks field types with cycle detection and
returns early from synthesize_blanket_impls when a recursive ADT
is found.

fixes #160105.

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @notriddle (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: rustdoc
• rustdoc expanded to 8 candidates
• Random selection from GuillaumeGomez, camelid, lolbinarycat, notriddle

[notriddle]

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 1701156 (1701156946ac94f71ac6fe1ac6110e8762eb2841)
Base parent: be3d26d (be3d26db984c6f96335faca1f254dc04873cb1c1)

[rust-timer]

Finished benchmarking commit (1701156): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

@bors rollup=never rustc-perf
@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)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.0%	[-3.5%, -0.2%]	9
Improvements ✅ (secondary)	-1.4%	[-2.4%, -0.3%]	3
All ❌✅ (primary)	-1.0%	[-3.5%, -0.2%]	9

Max RSS (memory usage)

Results (primary 0.5%, secondary -1.6%)

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

	mean	range	count
Regressions ❌ (primary)	2.7%	[0.4%, 4.1%]	3
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.2%	[-2.1%, -0.4%]	4
Improvements ✅ (secondary)	-1.6%	[-1.6%, -1.6%]	1
All ❌✅ (primary)	0.5%	[-2.1%, 4.1%]	7

Cycles

Results (primary -0.6%, secondary -2.6%)

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

	mean	range	count
Regressions ❌ (primary)	0.7%	[0.4%, 1.0%]	2
Regressions ❌ (secondary)	1.2%	[0.4%, 3.7%]	12
Improvements ✅ (primary)	-1.0%	[-3.2%, -0.4%]	7
Improvements ✅ (secondary)	-6.4%	[-21.5%, -0.4%]	12
All ❌✅ (primary)	-0.6%	[-3.2%, 1.0%]	9

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 489.155s -> 489.631s (0.10%)
Artifact size: 390.64 MiB -> 390.69 MiB (0.01%)

[fmease]

This is an extremely targeted fix that's also way too broad as it means that rustdoc stops showing blanket impls for all recursive data types which I don't consider acceptable.

The linked issue #160105 likely has the same root cause as #155759 and #114891.

The problem isn't with rustdoc's blanket impl synthesis, it's with the current trait solver. The next trait solver fixes this class of issues. Hence, I consider PR #125907 to be the principled fix (which is still blocked by some perf regressions caused by the switch).

What you're doing here is trying to patch faults of the trait solver from the outside just like PR #155765 which I'm also not a fan of.

View changes since the review

[im-lunex]

@fmease thanks for looking into it. I see the issue and i will love to have my time to look deeper into it.. and will inform as soon as i get something.

[im-lunex]

@fmease soo i dont see any way to fix this with the old trait solver. this must go under the new_trait_solver.. that you are already working on (#125907) here. soo you can close this PR..

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.