Support no_std compilation for various crates #6581

james7132 · 2022-11-13T11:24:13Z

Objective

Partially addresses #6370. Make many of the crates no_std.

Solution

Replace std with core and alloc.

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_std environments. Many still have dependencies with std deps.

- bevy_derive - bevy_ecs_macros - bevy_encase_derive - bevy_math - bevy_reflect_derive - bevy_render_macros - bevy_utils

james7132 · 2022-11-13T11:25:23Z

Going to assume this controversial by default due to the commitment and potential maintenance burden this may have.

mockersf · 2022-11-13T14:32:21Z

This does not guarantee all of these crates will build for no_std environments. Many still have dependencies with std deps.

Are at least a few of the crates no_std compatibles with this? Would it makes sense to add that check to CI for those / how long would it take?

james7132 · 2022-11-13T23:10:19Z

Quite a few of them are. The few that aren't usually require some kind of IO, since std::fs and std::net have zero core or alloc equivalents. Assets in particular may need to split between the type and ECS definitions and the actual IO implementation.

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 no_std enabled for the entire engine.

james7132 · 2022-11-14T10:06:15Z

Another major blocker I'm running into: thiserror has zero support for no_std. We could manually implement it, or find another no_std compatible error derive crate.

jfaz1 · 2023-09-23T06:45:12Z

Any chance we could split this PR up and extract some of the easier-but-essential crates that are compatible with no_std? I think most users wanting to use no_std right now are probably plugging in bevy_ecs and maybe bevy_transform/bevy_hierarchy into a separate ecosystem (e.g. Godot).
In my case I'm working on a small side project for PlayDate and all I'd really be able to plug in are those three (though all I really need is bevy_ecs.) I'm using HECS for the time being and it's working great but I'd like to use Bevy since that's what I'm using for my main project.

alice-i-cecile · 2024-03-08T19:34:13Z

I'm happy to review any smaller forms of this PR: breaking it up by chunks seems very appealing.

cart · 2024-03-08T19:47:01Z

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?

james7132 · 2024-03-08T19:54:55Z

The primary things that we'd be missing are, as far as I know:

std::thread and std::sync. These come up for parallelization and concurrency, but we already have ways of disabling threading. We may need to drop down to lock_api to find alternatives for the latter.
std::io is the other big one, which precludes a large portion of the asset-dependent crates. Thankfully we haven't started adding networking capabilities to first party crates yet other than in-browser fetches, but std::net would be another potential area that'd be impacted.
Platform integration crates (winit, wgpu, gilrs, etc) are platform specific and they'll need to be extended on a per-platform basis. Thankfully, bevy_window and bevy_input are operating as abstraction points, so they too could be ported over, and a separate platform integration for those could work. However, the tight coupling for bevy_render and wgpu means a subset of rendering will likely need to be carved out (i.e. the bevy-only types) to allow for swapping out wgpu on another platforms, or wgpu will need to be extended for that platform's support.

alloc is probably the biggest thing we cannot get rid of, and I don't think it makes sense to be running Bevy on a platform without heap memory allocation of any kind.

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.

james7132 · 2024-09-20T02:41:20Z

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>

james7132 added 11 commits November 13, 2022 01:57

Make crates no_std and forbid(unsafe_code)

a1fcede

- bevy_derive - bevy_ecs_macros - bevy_encase_derive - bevy_math - bevy_reflect_derive - bevy_render_macros - bevy_utils

Remove most of the std from bevy_reflect

1ec1046

More std -> core

64fe210

Make bevy_time no_std

ca96b96

Make bevy_transform no_std

d7762fa

Make bevy_hierarchy no_std

766464b

Make bevy_ecs no_std

3746051

Make bevy_app (almost) no_std, forbid(unsafe_code)

d835cf7

Make bevy_core (almost) no_std

a4794ce

Make bevy_internal no_std and forbid(unsafe_code)

bbf8e2e

Make bevy_macro_utils (almost) no_std

c4ca667

james7132 added 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 labels Nov 13, 2022

Formatting

8db4d53

Make bevy_winit no_std

e6b22bf

james7132 added 6 commits November 14, 2022 02:08

Make bevy_ui (almost) no_std

3b22674

Make bevy_text (almost) no_std

1675b62

Make bevy_sprite (almost) no_std

14fc008

Make bevy_scene (almost) no_std

2f80dfa

Make bevy_log no_std

e392ee9

Formatting

75ccc64

alice-i-cecile added the S-Adopt-Me The original PR author has no intent to complete this work. Pick me up! label Mar 8, 2024

This was referenced Sep 18, 2024

Allow bevy_utils in no_std Contexts #15279

Merged

Add core and alloc over std Lints #15281

Merged

james7132 closed this Sep 20, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support no_std compilation for various crates #6581

Support no_std compilation for various crates #6581

james7132 commented Nov 13, 2022

james7132 commented Nov 13, 2022

mockersf commented Nov 13, 2022

james7132 commented Nov 13, 2022 •

edited

Loading

james7132 commented Nov 14, 2022

jfaz1 commented Sep 23, 2023

alice-i-cecile commented Mar 8, 2024

cart commented Mar 8, 2024

james7132 commented Mar 8, 2024 •

edited

Loading

james7132 commented Sep 20, 2024

Support no_std compilation for various crates #6581

Support no_std compilation for various crates #6581

Conversation

james7132 commented Nov 13, 2022

Objective

Solution

james7132 commented Nov 13, 2022

mockersf commented Nov 13, 2022

james7132 commented Nov 13, 2022 • edited Loading

james7132 commented Nov 14, 2022

jfaz1 commented Sep 23, 2023

alice-i-cecile commented Mar 8, 2024

cart commented Mar 8, 2024

james7132 commented Mar 8, 2024 • edited Loading

james7132 commented Sep 20, 2024

james7132 commented Nov 13, 2022 •

edited

Loading

james7132 commented Mar 8, 2024 •

edited

Loading