fix: Check the fallback map before queueing child in visible_parent_map breadth-first search - #160464
Conversation
|
r? @nnethercote rustbot has assigned @nnethercote. Use Why was this reviewer chosen?The reviewer was selected based on:
|
visible_parent_map breadth-first-searchvisible_parent_map breadth-first search
|
@rustbot label +perf-regression |
|
Actually, after looking at PRs labeled @rustbot label -perf-regression |
|
That makes me think, maybe we could have a perf job that runs rustdoc on Cc @Kobzol |
|
Huh, those CI failures on Is my reading correct that the CI failure seems unrelated to this change and could be caused by something else? |
|
Looks like that job may be having some issues #t-infra > Tree ops @ 💬 |
|
The job Click to see the possible cause of the failure (guessed by this bot)Important For more information how to resolve CI failures of this job, visit this link. |
|
Validation with a minimal (no crates.io) reproducer, since this PR currently lacks performance evidence:
I also added a regression test at |
The fix in #159881 extended the
visible_parent_mapbreadth-first search (BFS) to include items nested within "fallback" items, such as#[doc(hidden)]modules and re-exports. However, the fix resulted in fallback entries not being checked before enqueueing new items into the BFS, resulting in fallback items being explored in the BFS multiple times, once for each fallback parent, up until a non-fallback visible parent is found instead, if any.This PR adds a check before new fallback items are recorded and the BFS queue is extended that ensures that the item has not already been searched through a fallback parent item.
Fixes the
libcperformance regression described in #160439.Unfortunately, I could not think of a way to write a test case that covers the regression that this PR fixes, as it would require a massive crate with a very large number of "fallback" parents, and the test would be performance-based.