Add new failed_merged_doctest_compilation rustdoc lint

[GuillaumeGomez]

Finally took the time to write this lint. We need to have a compiler context in order to be able to emit the lint, but I'm not sure if DiagCtxtHandle doesn't provide it somehow... Anyway, I'm expecting performance regression because we keep the compiler and its internals around for much longer, stacking doctests memory on top of the allocated memory to the current crate (which is why I'd really love to see if it's possible to emit lints from DiagCtxtHandle somehow, gonna investigate).

Also: both lint name and lint message are very much up to debate.

r? @fmease

[rustbot]

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

[GuillaumeGomez]

@bors2 try @rust-timer queue

[rust-log-analyzer]

The job pr-check-2 failed! Check out the build log: (web) (plain enhanced) (plain)

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

error: doctest failed, to rerun pass `-p alloc --doc`

Caused by:
  process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustdoc --edition=2024 --crate-type lib --color always --crate-name alloc --test library/alloc/src/lib.rs --test-run-directory /checkout/library/alloc --target x86_64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/release/deps -L native=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/build/compiler_builtins-ab4e95d684d268d9/out --test-args -Z --test-args unstable-options --test-args --format --test-args json --warn=unexpected_cfgs --check-cfg 'cfg(no_global_oom_handling)' --check-cfg 'cfg(no_rc)' --check-cfg 'cfg(no_sync)' --extern 'priv:alloc=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/liballoc-7ba7b7a48df3e66b.rlib' --extern 'priv:compiler_builtins=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/libcompiler_builtins-646e9c051dbeece2.rlib' --extern core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-std/x86_64-unknown-linux-gnu/release/deps/libcore-116781e8a0b7fefc.rlib -C embed-bitcode=no --cfg 'feature="compiler-builtins-c"' --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values("compiler-builtins-c", "compiler-builtins-mem", "compiler-builtins-no-f16-f128", "optimize_for_size"))' -Csymbol-mangling-version=legacy '--check-cfg=cfg(feature,values(any()))' -Zunstable-options -Dwarnings '-Wrustdoc::invalid_codeblock_attributes' --crate-version '1.93.0-nightly (e7571561e 2025-11-12)' '-Zcrate-attr=doc(html_root_url="https://doc.rust-lang.org/nightly/")' '-Zcrate-attr=warn(rust_2018_idioms)' --error-format human -Zunstable-options` (exit status: 1)
note: test exited abnormally; to see the full output pass --no-capture to the harness.
Bootstrap failed while executing `test --stage 1 core alloc std test proc_macro`
Build completed unsuccessfully in 0:06:41
  local time: Wed Nov 12 14:43:10 UTC 2025
  network time: Wed, 12 Nov 2025 14:43:10 GMT
##[error]Process completed with exit code 1.

[GuillaumeGomez]

Another thing I thought: should we display errors?

[rust-bors]

☀️ Try build successful (CI)
Build commit: fa55e90 (fa55e9058b427aeb73ae208b2105b8e21713b3b3, parent: 95aeb4696545eb4c9cbb68516f2912770e3846ea)

[rust-timer]

Finished benchmarking commit (fa55e90): comparison URL.

Overall result: no relevant changes - no action needed

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.

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

Instruction count

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

Max RSS (memory usage)

Results (primary 1.5%)

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

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

Cycles

Results (secondary -1.1%)

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

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

Binary size

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

Bootstrap: 474.976s -> 474.831s (-0.03%)
Artifact size: 391.06 MiB -> 391.05 MiB (-0.00%)

[bors]

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

[fmease]

What's the status of this PR? I've only given it a cursory glance. Perf came back clean, so does that mean the current approach can be taken or are there still other blockers?

Would you like me to review this code? I didn't review it so far because of the draft status & the failed CI (the failure seems to stem from lib alloc containing two unmergeable doctests).

View changes since this review

[fmease]

(preliminary review) this is always Some(_); I'm probably missing sth.

[fmease]

[…] I'd really love to see if it's possible to emit lints from DiagCtxtHandle somehow,

That's not possible, it doesn't contain the necessary information. DiagCtxtHandle just stores low-level things in order to properly emit diagnostics. For lints on the other hand we need to be able to check if they were suppressed via lint control attributes or flags (allow, expect) which form a hierarchy (apart from that, it needs access to the query system (so TyCtxt) & some other data that's stored in the Session).

[fmease]

I haven't taken a deeper look at the code yet, so I'm not fully up to speed re. all the constraints that are imposed here but I can say that if lack of access to TyCtxt is a problem (as you've alluded to in the PR description), consider "buffering" the lint instead of calling node_span_lint eagerly. That's what rustc also does / has to do for early lints, it just puts them into a vector and emits them at a later point where TyCtxt is available.

Hopefully this is relevant ^^' I've yet to take a proper look. Of course if you want to avoid keeping TyCtxt or Session or XYZ alive for a longer time, buffering won't help.