Add no_std support to wgpu-types

[bushrat011899]

Connections

• Contributes to Support no_std where possible (specifically for wasm32v1-none) #6826

Description
For a possible no_std version of wgpu (as requested in the above issue), a good first step would be for the already slim wgpu-types crate to be no_std compatible. This is what this PR accomplishes.

First, I disabled default features on the crates wgpu-types relies on (disabling their respective std features). As these dependencies are managed through the workspace, they had to be disabled there, requiring re-enabling default in the adjacent crates.

Next, I added std and default features to wgpu-types. This ensures users who do not care about no_std compatibility have minimal friction when using this crate. I also added the following lints to wgpu-types:

[lints.clippy]
std_instead_of_core = "warn"
std_instead_of_alloc = "warn"
alloc_instead_of_core = "warn"

These are very helpful when working on a crate with features for std and alloc, since they will inform you if you're being overly restrictive on how you import items which are re-exported.

Next, I added the following to the lib.rs file:

#![no_std]

#[cfg(feature = "std")]
extern crate std;

extern crate alloc;

By being unconditionally no_std and optionally including std through a feature, this crate will always use the core implicit prelude instead of switching between core and std based on the std feature. This was a headache in Bevy's no_std efforts.

Finally, I added appropriate feature gates where required, and tweaked one particular method for serializing Astc texture formats to ensure the serde feature didn't require the alloc one. There's nothing wrong with requiring alloc for serde, but it was a minor change to decouple these two features. Change isn't required but I've already written it, and it does avoid allocation, so it's marginally more performant. Reverted.

Testing
Tested through compiling wgpu-types using the following commands:

cargo check -p wgpu-types --no-default-features --target x86_64-unknown-none
cargo check -p wgpu-types --no-default-features --target x86_64-unknown-none --features strict_asserts,fragile-send-sync-non-atomic-wasm,serde,counters

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy. If applicable, add:
  • --target wasm32-unknown-unknown
  • --target wasm32-unknown-emscripten
• Run cargo xtask test to run tests.
• Add change to CHANGELOG.md. See simple instructions inside file.

Notes

I have made the assumption that conditional alloc may provide utility to this crate, but that may be faulty. It could be removed and the extern crate alloc line could always be included.

[cwfitzgerald]

Just one note while you're working on this, I don't think we need no-alloc support; the rest of the stack depends on it anyway.

[bushrat011899]

Just one note while you're working on this, I don't think we need no-alloc support; the rest of the stack depends on it anyway.

Easy, I've removed that feature and fixed (hopefully) the last CI issue too.

[cwfitzgerald]

Got some comments, but generally looking good.

The other thing that needs to be done is get CI support for a no-std platform so we don't break no-std.

Lets do testing on wasm32v1-none as that was the inciting incident for this work.

You can add another variant after https://github.com/gfx-rs/wgpu/blob/trunk/.github/workflows/ci.yml#L145-L148 which is the wasmv1 target. It will be a new kind called no-std and for now lets use the nightly toolchain, so add toolchain: nightly (not required but this makes setup easier)

Then add a new block similar to https://github.com/gfx-rs/wgpu/blob/trunk/.github/workflows/ci.yml#L234-L248 which is conditioned on if: matrix.kind == "no-std" and contains the exact things you were testing with. We can expand them as more of wgpu gets no-std access.

[bushrat011899]

Noting here that there is a bug in the current version of web-sys (0.3.76) which prevents compilation on the new wasm32v1-none platform. It has been resolved in this PR which is already merged. Until a new version of web-sys is published, wgpu-types will not compile on wasm32v1-none. However, by removing the ImageData feature (the one in web-sys that causes the current compiler error) I can see compilation fails within wgpu-types on web_sys::ImageData being missing. This indicates to me that this will successfully compile once web-sys publishes their next version.

[bushrat011899]

Ok I've addressed all the items from that review (thanks for being so thorough btw!). I've also added a new no_std kind of CI task with 2 matrix entries; one for bare-metal x86 (x86_64-unknown-none) and one for wasm32v1-none. As mentioned above, wasm32v1-none will fail until web-sys updates, so I included bare-metal x86 so we can verify that the CI task works as expected.

[cwfitzgerald]

Looking good. Have some notes about CI, and CI is mad.

[bushrat011899]

Addressed the latest round of comments and fixed that CI issue (forgot to cascade the change in Dx12Compiler::DynamicDxc to all crates)

[cwfitzgerald]

Bleh CI crap, I'll deal with this

[bushrat011899]

Ahh yeah looks like I forgot to rustup target add x86_64-unknown-none in the runner.

[cwfitzgerald]

Nah, I led you astray- I thought bare metal x86_64 was a tier 3 Target and therefore you actually can't tell it to install the target. This is what we have to do for vision OS and why there are two separate tool chain installation steps, but I now realize is one for tier 1 and 2 and one for tier 3

[cwfitzgerald]

I'm going to touch up the CI script to make the definitions more clear when I do the final proper pass on this PR

[cwfitzgerald]

Thanks for all the work!

[bushrat011899]

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.