do not rerun trait solver cycles on ambiguity

[lcnr]

See the comment in fn reached_fixpoint.

Fixes a minimization of the hang in fuchsia (even if it doesn't fix fuchsia itself) and may impact other hangs as well 🤷 doesn't fix the regression in diesel by itself

r? @compiler-errors

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[lqd]

may impact other hangs as well 🤷

As an example of other cases where this PR helps: it improves the new solver's current simili-hang on #125994 a lot.

[lcnr]

@rustbot ready

looked at rust-lang/chalk#48 and to my understanding their reasoning was about an implementation detail of chalk. I still don't fully get why they got hangs when rerunning goals, but it seems unrelated as we do "apply the constraints" from ambiguous results and the added test works with the new solver (after changing it to (): Sized<ty> to avoid the "self ty is infer" check).

[bors]

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

[compiler-errors]

@rustbot author

[jimblandy]

@lcnr @fmease Hi! Is there anything else blocking this? We're still effectively unable to build docs for wgpu-core.

[lqd]

@jimblandy are you sure you're commenting on the correct PR? This PR is for the new solver, and shouldn't help building docs for wgpu-core.

[jimblandy]

@jimblandy are you sure you're commenting on the correct PR? This PR is for the new solver, and shouldn't help building docs for wgpu-core.

Yes, I think I am commenting on the right PR:

• The original rustdoc issue is here: rustdoc: synthetic blanket impls: hang / very long compiletimes with complex mutually recursive structs involving many projections #114891
• @fmease refers to it in the initial comment for this issue: Next-gen solver: Compiler "hang" & eventual OOM when facing complex mutually recursive structs & many projections #126196.
• In this comment on that issue, @lncr says it should be fixed by this PR: Next-gen solver: Compiler "hang" & eventual OOM when facing complex mutually recursive structs & many projections #126196 (comment)

Honestly, I'm as surprised as you are, but here we are.

[fmease]

To clear things up, #114891 is due to something going wrong in the old solver (it can't be the next solver because it's not yet enabled by default). First, I minimized the issue here: #114891 (comment). Then, I profiled rustdoc and realized it had something to do with the (old) trait solver. However, I'm not particularly well-versed in either trait solver much less in the gnarly details around cycles & caching which seems to be the root cause.

So instead I decided to experimentally migrate the problematic rustdoc 'routine' (blanket impl synthesis) from the old to the next solver in #126196 to check if that might solve the problem. However, it turns out that the "rustc equivalent" of #114891 currently also hangs in the next solver (coincidentally I presume). For that, I opened #126196. This brings us to this PR which might unblock #126196 which in turn might fix #114891.

Getting slightly off-topic but unfortunately I don't know when and why #114891 regressed (since it's hard to bisect a compiletime or hang issue).

[lcnr]

merged as part of #128828