use hashbrown in naga & main wgpu crates etc.

[brody4hire]

Connections

• helpful for no-std support as requested in issue: Support no_std where possible (specifically for wasm32v1-none) #6826
• continuation of hashbrown updates introduced in PR: Start using hashbrown #6925

Description

• use hashbrown in naga & top-level wgpu crates
• completely replace indirect usage of std::collections::HashMap via rustc_hash::FxHashMap in wgpu-hal
• use hashbrown in main wgpu crate
• use hashbrown in deno_webgpu

POSSIBLE API IMPACT

Exported naga API with these updates would be exporting types & members using HashMap & HashSet from hashbrown rather than std::collections. I think this is a crucial part of supporting no-std. I don't expect the blast radius to be very high, just wanted to point this out to avoid potential surprises for anyone.

Loose ends:

• I have encountered some issues using hashbrown with spirv & Arbitrary, will investigate these over the weekend. ✅

/cc @bushrat011899

Testing

• cargo test --all-features -p naga
• cargo test --all-features -p wgpu-core
• cargo test --all-features -p wgpu-hal
• cargo test --all-features -p wgpu
• cargo xtask test

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.
• Resolve or defer XXX todo items in these updates

[brody4hire]

If I use hashbrown::HashSet without this update, cargo clippy (and cargo test with all features) fails with this:

error[E0277]: the trait bound `&spirv::Capability: hashbrown::Equivalent<spirv::Capability>` is not satisfied
   --> naga/src/back/spv/writer.rs:172:60
    |
172 | ...                   .find(|cap| available.contains(cap))
    |                                             -------- ^^^ the trait `std::borrow::Borrow<&spirv::Capability>` is not implemented for `spirv::Capability`, which is required by `&spirv::Capability: hashbrown::Equivalent<spirv::Capability>`
    |                                             |
    |                                             required by a bound introduced by this call
    |
    = note: required for `&spirv::Capability` to implement `hashbrown::Equivalent<spirv::Capability>`
note: required by a bound in `hashbrown::HashSet::<T, S, A>::contains`
   --> /Users/cjb/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.15.2/src/set.rs:864:19
    |
862 |     pub fn contains<Q>(&self, value: &Q) -> bool
    |            -------- required by a bound in this associated function
863 |     where
864 |         Q: Hash + Equivalent<T> + ?Sized,
    |                   ^^^^^^^^^^^^^ required by this bound in `HashSet::<T, S, A>::contains`

For more information about this error, try `rustc --explain E0277`.

It took me a while to figure out that using <spirv::Capability> in the hashbrown::HashSet::contains function call would resolve this build issue.

Something about this does not feel 100% right to me, wondering why rustc couldn't handle this call without using the type parameter. Any ideas about this?

[Wumpf]

serde should be enabled only via serialize/deserialize features. If there's something that needs serialization without those features that would be a bit fishy.