Repository navigation
cargo doc freezes on libc with nightly-2026-08-03 #160439
Description
Activity
@rustbot claim
I've got a fix ready for that visible_parent_map BFS hang. Should I just do a quick check, which should take about 20 minutes and doesn't need a full build, or would you rather I do a full stage1 build and run the #159881 UI suite and libc repro? That would take about 1 to 3 hours. Also, should I include a stress test with the fix?
@zalanlevai @fee1-dead it looks like #159881 broke documenting
libcand presumably others. If there isn't a quick fix, would we be able to revert it for now?Also @LusterSourav #160439 (comment) is pretty confusing. Always copy+paste code rather than using screenshots, wrap it in
``` ... ```, and there's no need to show the rustup commands or run via python (rustc -Vvthen running the command directly is fine)Also @LusterSourav #160439 (comment) is pretty confusing. Always copy+paste code rather than using screenshots, wrap it in
``` ... ```, and there's no need to show the rustup commands or run via python (rustc -Vvthen running the command directly is fine)okee
If there isn't a quick fix, would we be able to revert it for now?
@tgross35 I think I could get a quick fix together for this within the next couple of hours.
If there isn't a quick fix, would we be able to revert it for now?
@tgross35 I think I could get a quick fix together for this within the next couple of hours.
already fixed
I've got a fix ready for that visible_parent_map BFS hang. Should I just do a quick check, which should take about 20 minutes and doesn't need a full build, or would you rather I do a full stage1 build and run the #159881 UI suite and libc repro? That would take about 1 to 3 hours. Also, should I include a stress test with the fix?
just want to ask...
Just put up a PR that will run it for you? A test case that reproduces the issue would be great to have, yes
37 remaining items
- added a commit that references this issue
on Aug 31, 2026 - added a commit that references this issue
on Sep 9, 2026 - added 4 commits that reference this issue
on Sep 16, 2026 - added 2 commits that reference this issue
on Sep 29, 2026 - added a commit that references this issue
on Oct 1, 2026
View all comments
Starting on the nightly build from August 3rd, 2026,
cargo dochas been freezing when trying to build documentation for large projects.To see this happen, try running
cargo +nightly-2026-08-03 doc --workspace --no-depson a project like rust-lang/libc. This is especially noticeable if the project has a lot of items that are re-exported or modules marked with#[doc(hidden)].It should finish without issues, just like it did on the nightly build from August 2nd. Instead, the
rustdoc/rustcprocess gets stuck, uses a ton of CPU and memory, and is eventually killed after about 3.5 minutes with a SIGTERM signal (exit code 143). This problem is also causing the libc continuous integration tests to fail: https://github.com/rust-lang/libc/actions/runs/30800111327/job/91642485751The documentation build worked fine with:
nightly-2026-08-02 (1.99.0-nightly, commit 73dc916)
The issue started with:
rustc --version --verbose: rustc 1.99.0-nightly (11177f2 2026-08-02)
I can't provide a backtrace because the process just hangs; it doesn't crash.
I suspect the problem might be related to pull request #159881. This change modified how the
visible_parent_mapuses a Breadth-First Search (BFS) to go into children of#[doc(hidden)]modules. However, it seems fallback items are never marked as "visited." This means they get added back into the queue from every parent path, causing a huge increase in processing, especially with libc's module structure. I confirmed this by looking at the nightly build manifests: