use hashbrown in more 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
• use hashbrown with default-features = false, as needed to support no-std build
• other minor updates

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.

/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

[cwfitzgerald]

Looking generally good, some comments!

[cwfitzgerald]

This actually applies to more than just this section - we generally reserve the larger "Major Changes" items for breaking changes or very heavy refactors. So like when no-std lands in the whole stack, that definitely will deserve a large item. But for this, a single line is fine as this is all internal and not user facing.

[brody4hire]

Makes total sense, I just pushed updates to compress all of this info & remove the unmeasured performance speculation. I have also squished the older hashbrown changelog update into here, out of the other place. I think this should be much cleaner.

Incidentally for small edits like this, I wouldn't mind if the reviewer wants to make the edit as a co-author if we want to save time going back-and-forth. Totally up to your best judgment on this.

[cwfitzgerald]

Makes total sense, I just pushed updates to compress all of this info & remove the unmeasured performance speculation. I have also squished the older hashbrown changelog update into here, out of the other place. I think this should be much cleaner.

Nice

Incidentally for small edits like this, I wouldn't mind if the reviewer wants to make the edit as a co-author if we want to save time going back-and-forth. Totally up to your best judgment on this.

Yeah I do that for complex changes where explaining it is harder than just doing it :) For most cases though, commenting is easier than fully task switching to a new branch and getting out of "review" mode.

[bushrat011899]

Nice! Splitting out these "controversial" changes into more bite-sized pieces is really nice to review.

[cwfitzgerald]

One last iteration. Might be worth setting up a hashmap on a banned type list to properly enforce this at least until we're fully checking non-std.

[cwfitzgerald]

Oop wrong button sorry 😅

[brody4hire]

I think I have addressed comments from @bushrat011899 & @cwfitzgerald, which have all been really helpful. I have raised #6999 to reconsider the choice of hasher for HashMap (and HashSet). I would like to see if I can fix a couple more little things here.

[brody4hire]

I think this should be ready now. There may be a couple minor nits left, IMO not worth blocking this too much longer.

[nical]

@brody4hire One last rebase to address the branch conflicts and this should be good to go.

[cwfitzgerald]

Nice, thank you!

[brody4hire]

extra blank line here - my bad thought I removed it d'oh