Support no_std where possible (specifically for wasm32v1-none)

[Dinnerbone]

Is your feature request related to a problem? Please describe.
naga, wgpu and related crates should have std as a (default) feature, specifically for wasm32v1-none support.

Describe the solution you'd like
There's a hope to get the wasm ecosystem slowly shifting from wasm32-unknown-unknown to wasm32v1-none, which is hopefully stabilizing in rust 1.84. This is primarily because wasm32-unknown-unknown is something of a moving target and can change the browser requirements at will, which we recently discovered when older Safari stopped working 😅

The main differences between wasm32v1-none and wasm32-unknown-unknown are:

• It does not enable any wasm features by default (which means it won't arbitrarily break browser compatibility with rust updates)
• It has no std (as opposed to a stubbed pseudo-std)

Unfortunately, no_std is both a blessing and a curse: it's neat to get things using core/alloc where possible, but it sucks that the majority of the ecosystem needs churn to make this viable.

I've done a quick investigation and I think it's plausible to get at least web working in no_std, but potentially other platforms too. wgpu-types is the easiest to get no_std, it only needs it for one specific dx12 config. naga is possibly the second easiest crate, but it requires some work in dependencies. wgpu-core and wgpu-hal will need more work mostly surrounding the use of mutexes.

Describe alternatives you've considered
We could just not, but that means it's impossible to allow users of wgpu to have any control over which browsers they support.
We can also limit this to a specific set of features, there's no real need today for DX12 and no_std, for example.

[bushrat011899]

I think there's value in having even just a subset of wgpu be no_std compatible. For context, I'm working on making Bevy no_std compatible, and a big line in the sand right now is anything related to our rendering crates, since they're built around wgpu and would be almost impossible to make independent of wgpu for the sake of an std feature.

[rdrpenguin04]

This would also be useful for porting to game consoles, particularly console homebrew.

[cwfitzgerald]

We're definitely interested in having this, but will need to be from an outside contributor, so PR's welcome!

I think that it is important that when the first PR comes in to partially support no-std, we have a CI job to make sure we don't break it in the future. That could be as simple as adding this wasm target to CI.

[brody4hire]

@bushrat011899 wrote in #6892 (comment):

Thanks for the assistance in getting it over the line! I'm planning on looking into no_std for naga next, but I suspect that'll be a much longer process.

@bushrat011899 I am working on this update for wgpu-core, hope to have a PR ready with this soon. I am taking a slightly different approach and would appreciate your feedback on this. I have also raised a couple more PRs to help prepare for these updates (see recent references above).

I may consider hacking on wgpu-hal as well, if you are not already working on this.

Hope I am not stepping on any toes.

[bushrat011899]

Hope I am not stepping on any toes.

Not at all! Just happy to have more people working on no_std support!

[brody4hire]

FYI I have now got no-std build working with naga in my workarea, with really ugly hacking - unfortunately I need to take rest after a very long day, hope to raise a PR for this before the weekend. I have ended up learning quite a bit from this :)

---

P.S. Here is the branch I pushed to backup my workarea: https://github.com/brodycj/wgpu/tree/wipsave34asdf

This is based on PR #6926 for wgpu-core, only recommended for the super-brave!