rustdoc: synthetic blanket impls: hang / very long compiletimes with complex mutually recursive structs involving many projections

[jimblandy]

Problem

When I run cargo doc, it never terminates. Instead, it uses 100% of a CPU indefinitely.

Steps

1. git clone https://github.com/gents83/wgpu.git
2. cd wgpu
3. git checkout 91d872e1
4. cargo +nightly doc -p wgpu-core

That final command never seems to exit.

Notes

I'm running Fedora 38 and cargo 1.73.0-nightly (7c3904d6c 2023-08-14).

[weihanglo]

The change described in gfx-rs/wgpu#3626 (comment) contributing to this freeze is a bit too big to me. Is it possible for you to minimize the scope and the relevant part, so that people can focus on debugging withoug reading through all the changes?

BTW, this looks like a rustdoc issue, not a Cargo issue.

[weihanglo]

For more contexts, this failed from at least 1.64 to today's nightly.

[ehuss]

Transferred to rust-lang/rust since this appears to be a rustc/rustdoc issue.

In the logs, I see a stream of rustc_trait_selection::traits::project::normalize_with_depth_to calls with an ever increasing depth.

[ehuss]

Note for reproduction, you may need to git fetch origin pull/3626/head, since the given commit is on a PR.

[jimblandy]

The change described in gfx-rs/wgpu#3626 (comment) contributing to this freeze is a bit too big to me. Is it possible for you to minimize the scope and the relevant part, so that people can focus on debugging withoug reading through all the changes?

I can see how that would be helpful. Yes, it is a big change. Unfortunately, I won't be able to spend time reducing it further than I have.

Just for others - in the comment @weihanglo linked to, I was able narrow down which commit introduces the problem:

It seems like trunk merge gfx-rs/wgpu@5b34df5 is fine, but trunk merge gfx-rs/wgpu@91d872e hangs. It's specifically the merge of gfx-rs/wgpu@88f18ed (gfx-rs/wgpu#3691, "Don't implement Send or Sync on Wasm") that makes cargo doc hang.

[jimblandy]

Note for reproduction, you may need to git fetch origin pull/3626/head, since the given commit is on a PR.

Thank you for catching this. I've updated the "Steps" so that the given commit is actually there.

[chenyukang]

yes, I can reproduce it in local, seems evaluate_trait_predicate_recursively and evaluate_predicate_recursively are calling each other infinitely.