Fix recursion limits with next solver by nazar-pc · Pull Request #9953 · gfx-rs/wgpu

nazar-pc · 2026-07-28T14:50:16Z

Connections

Description

This is a much better alternative to #9609 that solves the same underlying issue. The root cause is that next solver has a really hard time figuring out auto traits and ultimately fails with default recursion limit.

I later discovered that this is infectious, meaning not only wgpu needs to raise limits, but any crate that uses a lot of its types. The solution is to help solver a little bit and implement the traits manually. The code is more or less a macro expansion from https://crates.io/crates/non_structural_derive applied to the core type that is used basically everywhere.

This small change removes the need to increase recursion limits both here and for downstream users and I believe should help with compilation time as well.

Testing

Checked whether workspace compiles with cargo clippy.

Checklist

I self-reviewed and fully understand this PR.
WebGPU implementations built with wgpu may be affected behaviorally.
Validation and feature gates are in place to confine behavioral changes.
Tests demonstrate the validation and altered logic works.
CHANGELOG.md entries for the user-facing effects of this change are present.
The PR is minimal, and doesn't make sense to land as multiple PRs.
Commits are logically scoped and individually reviewable.
The PR description has enough context to understand the motivation and solution implemented.

ErichDonGubler

This is pretty self-contained (minus a licensing issue I noticed), so I see no objection with it.

@jimblandy, @kpreid: I'm going to merge this in the next day or so (pending conversation in fee1-dead/non_structural_derive#1 (comment)), unless you have an objection.

ErichDonGubler · 2026-08-11T08:26:50Z

+/// This improves compilation performance and avoids a risk of dependents running into the default
+/// [`recursion_limit`] when checking types containing [`Global`]. This risk will become greater
+/// when Rust’s “next solver” is stabilized.
+///


question(non-blocking): Is there anything we can do to quantitatively substantiate this? Removing the recusion_limit attributes is enough to justify this, OFC, I was just curious if this significantly affected build timings at all (which is how I'd interpret "compilation performance" here).

ErichDonGubler · 2026-08-11T08:28:05Z

+///
+/// [`recursion_limit`]: https://doc.rust-lang.org/reference/attributes/limits.html#the-recursion_limit-attribute
+#[cfg(send_sync)]
+mod global_send_sync {


praise: Oooh, I really like keeping this all contained in a module with a single cfg. 😀

ErichDonGubler · 2026-08-11T08:30:03Z

-// `-Znext-solver` requires deeper recursion limits (at least for now) to prove Send/Sync
-#![recursion_limit = "256"]


praise: It's always nice to avoid recursion_limit attributes. I know that this is the same topic that introduced them in #9609, it's just nice to bend the trade-off curve.

ErichDonGubler · 2026-08-11T08:55:22Z

Rebased strictly to resolve the conflict that was present in the CHANGELOG.

Feedback appears satisfied.

kpreid · 2026-08-25T21:09:24Z

Today I was doing some work with nightly, and surprised to find that this PR hasn’t yet been merged.

I tried to rebase it to help it along, but I find that I do not know how it should interact with the recent wgpu-core-remote work, most particularly, #10074 saying "Global does not need to be Send or Sync".

andyleiserson · 2026-08-25T21:35:38Z

I guess the question is, if Global is no longer Send / Sync, what types are now causing problems with the new solver? Or do we need to put something (PhantomData<*const ()>?) in Global to help the solver conclude !Send/!Sync?

kpreid · 2026-08-26T17:01:06Z

From discussion in today’s meeting:

This change in its current form should be applied to the v30 branch, for the benefit of people who are using wgpu v30.
On trunk, Global is now part of wgpu-core-remote and is not used by wgpu. Therefore, the remaining question is: do we need to address any recursion limit issues in the new architecture?

I am testing with my application all-is-cubes and it seems that the answer is yes. For example, with a recursion_limit slightly reduced to 100 (to get a more useful report than one that shows only non-wgpu types in a different case):

warning: overflow evaluating the requirement `wgpu::Device: Sync`
  --> all-is-cubes-gpu/src/lib.rs:29:13
   |
29 | static FOO: wgpu::Device = todo!();
   |             ^^^^^^^^^^^^
   |
   = note: which requires `wgpu::dispatch::DispatchDevice: Sync`
   = note: which requires `Arc<wgpu::backend::wgpu_core::CoreDevice>: Sync`
   = note: which requires `wgpu::backend::wgpu_core::CoreDevice: Send`
   = note: which requires `wgpu::backend::wgpu_core::ContextWgpuCore: Send`
   = note: which requires `Arc<wgpu::wgpu_core::instance::Instance>: Send`
   = note: which requires `wgpu::wgpu_core::instance::Instance: Send`
   = note: which requires `wgpu::wgpu_core::instance::InstanceDevices: Send`
   = note: which requires `wgc::lock::vanilla::Mutex<wgc::weak_vec::WeakVec<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `lock_api::mutex::Mutex<wgpu_sync::mutex::RawMutex, wgc::weak_vec::WeakVec<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `wgc::weak_vec::WeakVec<wgpu::wgpu_core::device::Device>: Send`
   = note: which requires `Vec<alloc::sync::Weak<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `alloc::raw_vec::RawVec<alloc::sync::Weak<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `PhantomData<alloc::sync::Weak<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `alloc::sync::Weak<wgpu::wgpu_core::device::Device>: Send`
   = note: which requires `wgpu::wgpu_core::device::Device: Send`
   = note: and so on...

nazar-pc · 2026-08-26T18:05:41Z

Should I rebase and re-target this on v30 branch or open a new PR?

For the new version, I'm not sure it is worth investing into fixing something that doesn't happen with the default limit, but I can look into that once v30 is fixed if you want. Should be fairly easy now that we know how to address it.

kpreid · 2026-08-26T18:35:30Z

Should I rebase and re-target this on v30 branch or open a new PR?

I think re-targeting this PR makes sense.

For the new version, I'm not sure it is worth investing into fixing something that doesn't happen with the default limit,

Two considerations:

It’s near the default limit, which means that applications which put wgpu types in their own nontrivial types are likely to hit the limit, and this really isn’t their fault.
As you note in the PR description, it should help with compilation time (by moving the recursive Send/Sync checks from the dependents to wgpu-core itself). In graphics applications, iteration time is important, and so if we can do something reasonably-sized to help users’ code compile faster, we should.

I can look into that once v30 is fixed if you want.

I’d like to try doing it myself. I have an idea for how it should work: instead of trying to find the right place in the internals, how about we do it inside of wgpu/src/dispatch.rs, in the macro-generated dispatch enums? This nearly maximizes the benefit by doing it near the API surface, and only needs to be written once even as the API and implementation evolve.

kpreid · 2026-08-26T19:02:34Z

I’d like to try doing it myself. I have an idea for how it should work: instead of trying to find the right place in the internals, how about we do it inside of wgpu/src/dispatch.rs, in the macro-generated dispatch enums? This nearly maximizes the benefit by doing it near the API surface, and only needs to be written once even as the API and implementation evolve.

Posted #10177 — a draft PR, to see if CI immediately turns up any problems with this approach.

nazar-pc · 2026-08-26T19:14:33Z

Same 3 commits as before, rebased on v30 branch

kpreid

If it were my project, I’d hit the merge (squash) button on this now, but I’ve contributed code to this PR, so I shouldn’t be the one to merge it.

ErichDonGubler · 2026-08-27T08:40:25Z

From discussion in today’s meeting:

* This change in its current form should be applied to the v30 branch, for the benefit of people who are using wgpu v30.

* On trunk, `Global` is now part of `wgpu-core-remote` and is not used by `wgpu`. Therefore, the remaining question is: do we need to address any recursion limit issues in the _new_ architecture?
  I am testing with my application [`all-is-cubes`](https://github.com/kpreid/all-is-cubes/) and it seems that the answer is yes. For example, with a `recursion_limit` slightly reduced to 100 (to get a more useful report than one that shows only non-`wgpu` types in a different case):

warning: overflow evaluating the requirement `wgpu::Device: Sync`
  --> all-is-cubes-gpu/src/lib.rs:29:13
   |
29 | static FOO: wgpu::Device = todo!();
   |             ^^^^^^^^^^^^
   |
   = note: which requires `wgpu::dispatch::DispatchDevice: Sync`
   = note: which requires `Arc<wgpu::backend::wgpu_core::CoreDevice>: Sync`
   = note: which requires `wgpu::backend::wgpu_core::CoreDevice: Send`
   = note: which requires `wgpu::backend::wgpu_core::ContextWgpuCore: Send`
   = note: which requires `Arc<wgpu::wgpu_core::instance::Instance>: Send`
   = note: which requires `wgpu::wgpu_core::instance::Instance: Send`
   = note: which requires `wgpu::wgpu_core::instance::InstanceDevices: Send`
   = note: which requires `wgc::lock::vanilla::Mutex<wgc::weak_vec::WeakVec<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `lock_api::mutex::Mutex<wgpu_sync::mutex::RawMutex, wgc::weak_vec::WeakVec<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `wgc::weak_vec::WeakVec<wgpu::wgpu_core::device::Device>: Send`
   = note: which requires `Vec<alloc::sync::Weak<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `alloc::raw_vec::RawVec<alloc::sync::Weak<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `PhantomData<alloc::sync::Weak<wgpu::wgpu_core::device::Device>>: Send`
   = note: which requires `alloc::sync::Weak<wgpu::wgpu_core::device::Device>: Send`
   = note: which requires `wgpu::wgpu_core::device::Device: Send`
   = note: and so on...

This is missing the additional conclusion that I explicitly drove in the meeting that we were going to opt out of guaranteeing Send and Sync for Global, i.e., via a PhantomData<*const ()> member (though N.B. that it's no longer going to be used by wgpu or even wgpu-core directly). I'll raise this as a review issue in #10177.

EDIT: Raised: #10177 (review)

EDIT 2: Filed a PR for Global at #10180.

ErichDonGubler · 2026-08-27T09:17:49Z

CC @cwfitzgerald: ☝🏻 This is a backport now.

…ly (bevyengine#25512) # Objective - Improve compile times in `bevy_render` - Help with bevyengine#25511 ## Solution While investigating a wgpu trait overflow issue with the new solver I noticed that eagerly computing its `Send`/`Sync` reduces the compile time of `bevy_render` by around 10 seconds (on my machine debug goes from 20s to 9s and release from 26s to 15s). I don't like too much having to expose all these types though, and we might get the same perf benefits if gfx-rs/wgpu#9953 is merged though (edit: I tested with that PR changes and that alone reduces compile times by ~6 seconds, however when this PR is added it reduces another ~4 seconds). I also ended up removing the `Arc`s used in some of the wgpu wrapper types, as all wgpu types now use `Arc`s under the hood or equivalent. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

…ly (bevyengine#25512) - Improve compile times in `bevy_render` - Help with bevyengine#25511 While investigating a wgpu trait overflow issue with the new solver I noticed that eagerly computing its `Send`/`Sync` reduces the compile time of `bevy_render` by around 10 seconds (on my machine debug goes from 20s to 9s and release from 26s to 15s). I don't like too much having to expose all these types though, and we might get the same perf benefits if gfx-rs/wgpu#9953 is merged though (edit: I tested with that PR changes and that alone reduces compile times by ~6 seconds, however when this PR is added it reduces another ~4 seconds). I also ended up removing the `Arc`s used in some of the wgpu wrapper types, as all wgpu types now use `Arc`s under the hood or equivalent. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

nazar-pc force-pushed the fix-recursion-limits-next-solver branch 2 times, most recently from e1928b5 to d7c5a2c Compare July 28, 2026 15:01

This comment was marked as resolved.

Sign in to view

nazar-pc force-pushed the fix-recursion-limits-next-solver branch from d7c5a2c to 38dc8c9 Compare July 28, 2026 15:02

lcnr reviewed Jul 28, 2026

View reviewed changes

Comment thread wgpu-core/src/global.rs Outdated

nazar-pc force-pushed the fix-recursion-limits-next-solver branch from 38dc8c9 to 2933700 Compare July 28, 2026 15:09

nazar-pc mentioned this pull request Jul 28, 2026

Next solver: recursion limit triggered on downstream packages rust-lang/rust#160036

Open

nazar-pc force-pushed the fix-recursion-limits-next-solver branch from 2933700 to caf0552 Compare July 28, 2026 15:12

inner-daemons self-requested a review July 29, 2026 15:43

Wumpf assigned jimblandy Jul 29, 2026

andyleiserson reviewed Jul 29, 2026

View reviewed changes

Comment thread wgpu-core/src/global.rs Outdated

This comment was marked as outdated.

Sign in to view

This comment was marked as resolved.

Sign in to view

nazar-pc force-pushed the fix-recursion-limits-next-solver branch from caf0552 to ab22123 Compare July 29, 2026 15:57

nazar-pc requested a review from jimblandy July 29, 2026 15:57

kpreid requested changes Jul 29, 2026

View reviewed changes

Comment thread wgpu-core/src/global.rs Outdated

nazar-pc requested a review from kpreid July 31, 2026 04:29

kpreid force-pushed the fix-recursion-limits-next-solver branch from 3207e16 to acc16f5 Compare July 31, 2026 16:26

kpreid approved these changes Jul 31, 2026

View reviewed changes

This comment was marked as resolved.

Sign in to view

andyleiserson added the area: core Issues related to wgpu-core label Aug 5, 2026

inner-daemons removed their request for review August 5, 2026 23:17

This comment was marked as resolved.

Sign in to view

ErichDonGubler mentioned this pull request Aug 11, 2026

Detect odd characters in the CHANGELOG check #10041

Closed

This comment was marked as resolved.

Sign in to view

ErichDonGubler approved these changes Aug 11, 2026

View reviewed changes

ErichDonGubler added the changelog: released entry changed Allows the PR to modify released. This is uncommon. label Aug 11, 2026

ErichDonGubler force-pushed the fix-recursion-limits-next-solver branch from acc16f5 to 1c380d1 Compare August 11, 2026 08:55

github-project-automation Bot moved this to To triage in Triage Aug 21, 2026

nazar-pc mentioned this pull request Aug 22, 2026

Update Rust toolchain to the latest nightly nazar-pc/abundance#772

Merged

SkiFire13 mentioned this pull request Aug 22, 2026

Switch WgpuWrapper to a macro and have it compute Send/Sync eagerly bevyengine/bevy#25512

Merged

lcnr mentioned this pull request Aug 22, 2026

bevy_render 0.19.1 doesn't compile on current Rust nightly due to -Znext-solver enabled by default bevyengine/bevy#25511

Closed

ErichDonGubler moved this from To triage to Small in Triage Aug 26, 2026

ErichDonGubler assigned ErichDonGubler and unassigned jimblandy Aug 26, 2026

kpreid mentioned this pull request Aug 26, 2026

Explicitly implement Send and Sync for all wgpu dispatch types. #10177

Merged

8 tasks

nazar-pc and others added 3 commits August 26, 2026 22:10

Remove stray non-breaking space from changelog.

6707151

Fix recursion limits with next solver

b253405

fixup! Fix recursion limits with next solver

17d1182

nazar-pc force-pushed the fix-recursion-limits-next-solver branch from 755831b to 17d1182 Compare August 26, 2026 19:13

nazar-pc changed the base branch from trunk to v30 August 26, 2026 19:13

andyleiserson mentioned this pull request Aug 26, 2026

Uplifts to firefox-153 branch #10170

Merged

kpreid approved these changes Aug 27, 2026

View reviewed changes

ErichDonGubler merged commit 73a7e97 into gfx-rs:v30 Aug 27, 2026

github-project-automation Bot moved this from Small to Done in Triage Aug 27, 2026

ErichDonGubler mentioned this pull request Aug 27, 2026

fix(core-remote)!: Opt Global out of Send and Sync #10180

Open

8 tasks

nazar-pc deleted the fix-recursion-limits-next-solver branch August 27, 2026 11:27

		// `-Znext-solver` requires deeper recursion limits (at least for now) to prove Send/Sync
		#![recursion_limit = "256"]

Uh oh!

Conversation

nazar-pc commented Jul 28, 2026

Uh oh!

This comment was marked as resolved.

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

This comment was marked as resolved.

Uh oh!

Uh oh!

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

ErichDonGubler left a comment

Choose a reason for hiding this comment

Uh oh!

ErichDonGubler Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ErichDonGubler Aug 11, 2026

Choose a reason for hiding this comment

Uh oh!

ErichDonGubler Aug 11, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ErichDonGubler commented Aug 11, 2026

Uh oh!

kpreid commented Aug 25, 2026

Uh oh!

andyleiserson commented Aug 25, 2026

Uh oh!

kpreid commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nazar-pc commented Aug 26, 2026

Uh oh!

kpreid commented Aug 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kpreid commented Aug 26, 2026

Uh oh!

nazar-pc commented Aug 26, 2026

Uh oh!

kpreid left a comment

Choose a reason for hiding this comment

Uh oh!

ErichDonGubler commented Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ErichDonGubler commented Aug 27, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

ErichDonGubler Aug 11, 2026 •

edited

Loading

kpreid commented Aug 26, 2026 •

edited

Loading

kpreid commented Aug 26, 2026 •

edited

Loading

ErichDonGubler commented Aug 27, 2026 •

edited

Loading