Exponential (?) time complexity in `evaluate_trait_predicate_recursively` in rustdoc when proving Send/Sync

[Noratrieb]

There is a latent bug in parallel rustdoc that hangs in x.py doc compiler/rustc_driver --stage=1 when parallel_compiler is enabled.

This is currently blocking #104754 and #106745.

[m-ou-se]

From the thread on #106745:

It only happens when rust.parallel-compiler = true is enabled, which explains why it only happens in the -alt builder.

It gets stuck in rustc_trait_selection somehow. Here's a backtrace: backtrace.txt

No clue what is happening.

It looks like this recurses infinitely:

• evaluate_stack
• evaluate_candidate
• evaluate_predicates_recursively
• evaluate_predicate_recursively
• evaluate_trait_predicate_recursively
• evaluate_stack (and repeat)

Opened a Zulip thread about this.

[m-ou-se]

Temporary fix here: #107121

[m-ou-se]

Interestingly, ./x.py doc --stage 0 compiler/rustc_middle also gets stuck. I believe that runs the beta (non-parallel) rustdoc. So that'd mean that rustdoc gets stuck when documenting parallel rustc, not that parallel rustdoc gets stuck when documenting rustc.

[m-ou-se]

Both of the PRs that are blocked by this issue are changes that change the ast.

[m-ou-se]

It seems it's not an infinite loop, but just bad (exponential?) time complexity somewhere. @oli-obk suggested trying out what happens when explicitly implementing Send and Sync for the new ast node, and that indeed 'fixes' the problem in #106745:

#[cfg(parallel_compiler)]
unsafe impl Sync for FormatArgs {}

#[cfg(parallel_compiler)]
unsafe impl Send for FormatArgs {}

So this issue has almost nothing to do with parallel compiler. It occurs in regular non-parallel rustdoc. It's just that with cfg(parallel_compiler), the ast is Send and Sync, and apparently that takes a huge amount of time to prove when documenting rustc_middle.

(Oli is investigating.)