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

[ErichDonGubler]

Connections

• Prompted by discussion in Fix recursion limits with next solver #9953 and the 2026-08-26 wgpu maintainers' meeting.
• See also an opting in to Send and Sync for other types in Explicitly implement Send and Sync for all wgpu dispatch types. #10177.

Description

Now that Global is only intended to be consumed by downstreams who will be using from a single thread, we'd like to be conservative with what we promise for it. Opt out of Send and Sync for Global by adding a PhantomData<*const ()> member for it.

N.B. that this also includes the replacement of an NBSP, lifted from @nazar-pc's contribution in #9953 (which ended up being retarget to v30 instead of trunk).

Testing

An according assert_not_impl_any!(…) call has been added to wgpu-core-remote.

Squash or Rebase? Rebase.

Checklist

• I self-reviewed and fully understand this PR.
• WebGPU implementations built with wgpu may be affected behaviorally. Not at all.
• Validation and feature gates are in place to confine behavioral changes. None needed.
• Tests demonstrate the validation and altered logic works.
• CHANGELOG.md entries for the user-facing effects of this change are present. Typical wgpu downstreams won't use Global any more, so I didn't add an entry.
• 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.

[sagudev]

Now that Global is only intended to be consumed by downstreams who will be using from a single thread, we'd like to be conservative with what we promise for it. Opt out of Send and Sync for Global by adding a PhantomData<*const ()> member for it.

I understand why one would want assert_impl_any!(_: Send, Sync) (to ensure we do not break anything if someone relied on it). But I fail to see why anybody would want to conserve !Send and !Sync. Currently it just allows us to make more optimal code, but that does not need to hold true in the future. I do not see any harm if Global would get Send&Sync back "by accident" in the future.

[sagudev]

Are these changes intended to be here?

[ErichDonGubler]

Yes, because we should no longer need them. I suppose I should break this out into a separate commit, explaining why it's relevant. Will do that shortly.

[ErichDonGubler]

Ah, actually, maybe these hunks should move to #10177? If that lands first, then I'll keep things here. If not, maybe it'd make sense to roll them into #10177 instead (CC @kpreid).

[ErichDonGubler]

After a force-push, these hunks have been broken out to ee6b929 (CC @nazar-pc, who is credited with Co-Authored-By).

[sagudev]

Ah, actually, maybe these hunks should move to #10177?

That would make more sense to me rather than having them here as this PR does nothing wgc/wgpu otherwise.

[ErichDonGubler]

… I fail to see why anybody would want to conserve !Send and !Sync. Currently it just allows us to make more optimal code, but that does not need to hold true in the future. I do not see any harm if Global would get Send&Sync back "by accident" in the future.

I agree that the question of whether Global is Send + Sync or not is not particularly consequential. However, leaving it to be determined by the Rust compiler has exposed a few perf. problems for the new resolver, which was the motivation of #9953 (which is linked in the OP). We can avoid these problems by committing Global to a stance. This doesn't mean that the specific stance is important, though; if we determine that we really do need it to be Send + Sync again, then we enforcing it a la #10177 should be straightforward.

[sagudev]

Aha, so this is some kind of future proofing. If in the future it would become Send/Sync again we would also be close to recursion limit again.

[ErichDonGubler]

Rebased to resolve conflicts.

[cwfitzgerald]

One note that CI is mad about, but then LGTM.

[ErichDonGubler]

I'm not sure why Miri is failing now. This should only simplify the amount of work the compiler has to do. I wonder what I'm missing…and wish I could prioritize this sort of change this week. 😩

[kpreid]

The compiler still has to try evaluating the auto trait requirement.

Does it make any difference if the _prevent_send_and_sync field is first instead of last? That will cut off the check sooner if field order is also traversal order.

[andyleiserson]

The error now is on a different type:

error: overflow evaluating the requirement `backend::wgpu_core::CoreCommandEncoder: dispatch::CommonTraits`
    --> wgpu/src/backend/wgpu_core.rs:1795:44
     |
1795 | impl dispatch::CommandEncoderInterface for CoreCommandEncoder {
     |                                            ^^^^^^^^^^^^^^^^^^

This one I think showed up later, not at the same time that we started having problems (could be due to further compiler changes, could be due to our type becoming more complex), and unlike Global, it is still Send/Sync. In #10225 on the v30 branch, I added manual send/sync for this one (well, for a type somewhere in the hierarchy that makes up a CoreComandEncoder; in some cases I made the fix on a different type than the one in the error message to try and more evenly break down the complex nested structures, can't remember if this was such a case).