Support no_std compilation for various crates#6581
Support no_std compilation for various crates#6581james7132 wants to merge 19 commits intobevyengine:mainfrom
Conversation
- bevy_derive - bevy_ecs_macros - bevy_encase_derive - bevy_math - bevy_reflect_derive - bevy_render_macros - bevy_utils
|
Going to assume this controversial by default due to the commitment and potential maintenance burden this may have. |
Are at least a few of the crates |
|
Quite a few of them are. The few that aren't usually require some kind of IO, since By specifying a crate being no_std, it already doesn't load the stdlib while compiling, so I don't think we need a CI job to check this until we have |
|
Another major blocker I'm running into: |
|
Any chance we could split this PR up and extract some of the easier-but-essential crates that are compatible with |
|
I'm happy to review any smaller forms of this PR: breaking it up by chunks seems very appealing. |
|
Its worth exploring + discussing what the bounds should be for this. no_std is limiting and less documented/familiar/standard. Is a full port / hard no_std requirement viable? What ecosystem crates would we be leaving behind? If a full port isn't viable, how targeted should we be? What crates yield the most fruit cost-benefit-wise (ex: bevy_ecs comes up the most regularly). Should we port examples if we know a full port isn't viable? |
|
The primary things that we'd be missing are, as far as I know:
This likely precludes most of the engine given our dependencies on many of these parts. |
# 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.
|
Closing in favor of #15281. |
# Objective - Fixes #6370 - Closes #6581 ## Solution - Added the following lints to the workspace: - `std_instead_of_core` - `std_instead_of_alloc` - `alloc_instead_of_core` - Used `cargo +nightly fmt` with [item level use formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Item%5C%3A) to split all `use` statements into single items. - Used `cargo clippy --workspace --all-targets --all-features --fix --allow-dirty` to _attempt_ to resolve the new linting issues, and intervened where the lint was unable to resolve the issue automatically (usually due to needing an `extern crate alloc;` statement in a crate root). - Manually removed certain uses of `std` where negative feature gating prevented `--all-features` from finding the offending uses. - Used `cargo +nightly fmt` with [crate level use formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Crate%5C%3A) to re-merge all `use` statements matching Bevy's previous styling. - Manually fixed cases where the `fmt` tool could not re-merge `use` statements due to conditional compilation attributes. ## Testing - Ran CI locally ## Migration Guide The MSRV is now 1.81. Please update to this version or higher. ## Notes - This is a _massive_ change to try and push through, which is why I've outlined the semi-automatic steps I used to create this PR, in case this fails and someone else tries again in the future. - Making this change has no impact on user code, but does mean Bevy contributors will be warned to use `core` and `alloc` instead of `std` where possible. - This lint is a critical first step towards investigating `no_std` options for Bevy. --------- Co-authored-by: François Mockers <francois.mockers@vleue.com>
# Objective - Fixes bevyengine#6370 - Closes bevyengine#6581 ## Solution - Added the following lints to the workspace: - `std_instead_of_core` - `std_instead_of_alloc` - `alloc_instead_of_core` - Used `cargo +nightly fmt` with [item level use formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Item%5C%3A) to split all `use` statements into single items. - Used `cargo clippy --workspace --all-targets --all-features --fix --allow-dirty` to _attempt_ to resolve the new linting issues, and intervened where the lint was unable to resolve the issue automatically (usually due to needing an `extern crate alloc;` statement in a crate root). - Manually removed certain uses of `std` where negative feature gating prevented `--all-features` from finding the offending uses. - Used `cargo +nightly fmt` with [crate level use formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Crate%5C%3A) to re-merge all `use` statements matching Bevy's previous styling. - Manually fixed cases where the `fmt` tool could not re-merge `use` statements due to conditional compilation attributes. ## Testing - Ran CI locally ## Migration Guide The MSRV is now 1.81. Please update to this version or higher. ## Notes - This is a _massive_ change to try and push through, which is why I've outlined the semi-automatic steps I used to create this PR, in case this fails and someone else tries again in the future. - Making this change has no impact on user code, but does mean Bevy contributors will be warned to use `core` and `alloc` instead of `std` where possible. - This lint is a critical first step towards investigating `no_std` options for Bevy. --------- Co-authored-by: François Mockers <francois.mockers@vleue.com>
Objective
Partially addresses #6370. Make many of the crates
no_std.Solution
Replace
stdwithcoreandalloc.Also sprinkles a few
forbid(unsafe_code)where it's trivial to add it to a crate.This does not guarantee all of these crates will build for
no_stdenvironments. Many still have dependencies withstddeps.