e5158ed96c
# Objective I experienced an issue where `HashMap::new` was not returning a value typed appropriately for a `HashMap<K,V>` declaration that omitted the Hasher- e.g. the Default Hasher for the type is different than what the `new` method produces. After discussion on discord, this appears to be an issue in `hashbrown`, and working around it would be very nontrivial, requiring a newtype on top of the `hashbrown` implementation. Rather than doing that, it was suggested that we add docs to make the issue more visible and provide a clear workaround. ## Solution Updated the docs for `bevy_platform_support::collections`. I couldn't update Struct docs because they're re-exports, so I had to settle for the module. Note that the `[HashMap::new]` link wasn't generating properly- I'm not sure why. I see the method in the docs.rs site, https://docs.rs/hashbrown/0.15.1/hashbrown/struct.HashMap.html#method.new, but not on the generated internal documentation. I wonder if `hashbrown` isn't actually implementing the new or something? ## Testing n/a although I did generate and open the docs on my Ubuntu machine. --- ## Showcase before:  after:  --------- Co-authored-by: Zachary Harrold <zac@harrold.com.au> |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
Bevy Platform Support
Rust is a fantastic multi-platform language with extensive support for modern targets through its standard library.
However, some items within the standard library have alternatives that are better suited for Bevy and game engines in general.
Additionally, to support embedded and other esoteric platforms, it's often necessary to shed reliance on std, making your crate no_std.
These needs are handled by this crate, bevy_platform_support.
The goal of this crate is to provide alternatives and extensions to the Rust standard library which minimize friction when developing with and for Bevy across multiple platforms.
Getting Started
Like any dependency from crates.io, use cargo to add it to your Cargo.toml file:
cargo add bevy_platform_support
Now, instead of importing from std you can use bevy_platform_support for items it has alternative for.
See the documentation for what items are available, and explanations for why you may want to use them.
no_std Support
By default, bevy_platform_support will activate the std feature, requiring access to the std crate for whichever platforms you're targeting.
To use this crate on no_std platforms, disable default features:
bevy_platform_support = { version = "x.y.z", default-features = false }
Features
std (default)
Enables usage of the standard library. Note that where this crate has alternatives to the standard library that it considers better than what's provided, it will provide the alternative even when std is enabled.
This is explicitly incompatible with no_std targets.
alloc (default)
Enables usage of the alloc crate. Note that this feature is automatically enabled when enabling std.
This is compatible with most no_std targets, but not all.
critical-section
Switches to using critical-section as a backend for synchronization.
You may need to enable this feature on platforms with little to no support for atomic operations.