Prefer core and alloc over std where possible
#6370
Labels
A-Cross-Cutting
Impacts the entire engine
C-Code-Quality
A section of code that is hard to understand or change
X-Controversial
There is active debate or serious implications around merging this PR
Comments
alice-i-cecile
added
the
C-Code-Quality
|
I would add a O-Console label here, but we don't have one yet :P |
alice-i-cecile
added
the
X-Controversial
|
Real fast attempt applying this just to bevy_transform and bevy_time, found some quick blockers.
|
|
|
This was referenced Sep 18, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
Sep 18, 2024
# Objective - Adjust `bevy_utils` to make it `no_std` compatible - Partially replaces #6581 - Contributes to #8161 - Contributes to #6370 ## Solution Added `alloc` and `std` features to `bevy_utils` (`std` is enabled by default), allowing the crate's use in `no_std` contexts. ## Testing - CI passed locally. - Used `bevy_utils` in a `no_std` crate as an experiment and compiled successfully. ## Migration Guide If you were importing `bevy_utils` and setting `default_features` to `false`, but relying on elements which are now gated behind the `std` or `alloc` features, include the relevant feature in your `Cargo.toml`. ## Notes - Bevy already includes a single `no_std` crate, `bevy_ptr`, so there is precedent for this change. - As `bevy_utils` is widely used across the rest of Bevy, further work to make Bevy `no_std` compatible would be blocked on this crate, if such work was to be undertaken. - Most of the changes in this PR are just the removal of an unnecessary call to `to_string()` within unit tests.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What problem does this solve or what need does it fill?
Some less common platforms (e.g. Nintendo Switch, and likely other consoles), do not support the full Rust standard library.
Bevy uses a number of features from the standard library, but it's unclear exactly which parts need to be disabled (or replaced) in order to achieve these ports.
What solution would you like?
Add and follow the three lints listed in rust-lang/rust-clippy#9103.
This will have no effect on existing platforms (these are just re-exports), but will make it much clearer which crates (and features within crates) are
no_stdcompatible.We should enable these lints at the level of each crate in their lib.rs, in order to make the dev experience less frustrating due to desyncs with CI.
What alternative(s) have you considered?
Obviously, console devs can simply make these changes in their own fork. However, making this change comes at very little cost, and reduces the frustration of keeping forks synchronized.
Additional context
See this thread for discussion about no_std requirements for the official Switch target.
The text was updated successfully, but these errors were encountered: