Add implied bounds to generic types, impl Trait, and assoc types.

[obi1kenobi]

Include implied and elaborated (henceforth, implied) bounds in the rustdoc JSON representations of associated types, impl Trait types, and generic type parameters. Implemented as a new implied_bounds: Vec<GenericBound> field, alongside the existing bounds: Vec<GenericBound> field that stores explicit (syntactic) bounds. An attempt at implementing #143197, based on the feedback and discussion in #143559 (comment).

Rustdoc JSON distingushes between explicit bounds specified together with the generic parameter definition versus ones given via where clauses (which we do not change). The design of this PR considers implied bounds an inherent property of the generic type parameter, and does not distinguish the source of the implied bound between the two sets of explicit bounds. I believe this simplifies the design and implementation without hurting any use existing or realistic future use case.

Recommended review order:

• src/rustdoc-json-types/lib.rs
• src/librustdoc/clean/types.rs
• src/librustdoc/clean/mod.rs
• remainder of implementation, which is predominantly plumbing
• test suite

Partial list of remaining tasks

• See if there's a better way to determine if a def_id corresponds to a stable lang item trait (c.f. clause_to_generic_bound())
• Double-check whether the "presumably unreachable" arms are actually unreachable and convert to unreachable!() as needed
• Consider moving implied bounds logic out of clean/mod.rs to avoid file length tidy issue
• Consider implementing implied_outlives for lifetimes, or leave it for a subsequent PR
• See if any of the type size increases can be avoided with better choices of types
• See if any not-yet-stable Rust features invalidate any of my assumptions
• Resolve any other outstanding TODOs in the code or tests

r? fmease

cc @aDotInTheVoid

[rustbot]

fmease is currently at their maximum review capacity.
They may take a while to respond.

[obi1kenobi]

I'm still not particularly familiar with rustdoc or rustc internals, and I definitely don't have very good intuition for how things work yet. This PR is approximately 80h of me doing my best to figure things out on my own. I don't expect I got everything right—there are probably things that could be improved. But I did write lots of tests with all the edge cases I could think of, and I tried hard not to write anything egregiously wrong :)

Feedback is very welcome, as is advice on resolving the remaining TODOs. In particular, let me know if you have a preference between adding implied_outlives to generic lifetime parameters in PR vs in a future one.

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

fmt: checked 6533 files
tidy check
tidy [rustdoc_json (src)]: `rustdoc-json-types` modified, checking format version
tidy: Skipping binary file check, read-only filesystem
tidy [style (src)]: /checkout/src/librustdoc/clean/mod.rs:611: TODO is used for tasks that should be done before merging a PR; If you want to leave a message in the codebase use FIXME
tidy [style (src)]: /checkout/src/librustdoc/clean/mod.rs:629: TODO is used for tasks that should be done before merging a PR; If you want to leave a message in the codebase use FIXME
tidy [style (src)]: /checkout/src/librustdoc/clean/mod.rs: too many lines (3153) (add `// ignore-tidy-filelength` to the file to suppress this error)
tidy [style (src)]: FAIL
tidy [style (tests)]: /checkout/tests/rustdoc-json/implied-bounds-multi-lifetimes.rs:26: TODO is used for tasks that should be done before merging a PR; If you want to leave a message in the codebase use FIXME
tidy [style (tests)]: FAIL
removing old virtual environment
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'venv'
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'virtualenv'
Requirement already satisfied: pip in ./build/venv/lib/python3.10/site-packages (25.2)
Collecting pip
---
info: ES-Check: there were no ES version matching errors!  🎉
typechecking javascript files
tidy: The following checks failed: style (src), style (tests)
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy /checkout /checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo /checkout/obj/build 4 /node/bin/npm --extra-checks=py,cpp,js,spellcheck` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1549:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1280:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:03:10
  local time: Sun Nov  2 04:51:55 UTC 2025
  network time: Sun, 02 Nov 2025 04:51:55 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

[aDotInTheVoid]

i’ll take a look at the code later, but for now:

@bors try @rust-timer queue

[rust-bors]

☀️ Try build successful (CI)
Build commit: 972828a (972828af4644b91a03dc856d943eb07c56de72a0, parent: bd3ac0330018c23b111bbee176f32c377be7b319)

[rust-timer]

Finished benchmarking commit (972828a): 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)	0.4%	[0.1%, 3.0%]	14
Regressions ❌ (secondary)	0.3%	[0.1%, 0.4%]	20
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.1%	[-0.2%, -0.1%]	2
All ❌✅ (primary)	0.4%	[0.1%, 3.0%]	14

Max RSS (memory usage)

Results (primary 2.0%, 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.0%	[1.2%, 3.1%]	12
Regressions ❌ (secondary)	1.6%	[1.2%, 2.7%]	9
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.0%	[1.2%, 3.1%]	12

Cycles

Results (primary 2.6%, secondary -4.2%)

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

	mean	range	count
Regressions ❌ (primary)	2.6%	[2.6%, 2.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-4.2%	[-4.6%, -3.9%]	2
All ❌✅ (primary)	2.6%	[2.6%, 2.6%]	1

Binary size

Results (primary 1.1%)

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

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

Bootstrap: 474.434s -> 474.73s (0.06%)
Artifact size: 390.87 MiB -> 390.95 MiB (0.02%)