Add `no_std` support to `bevy` by bushrat011899 · Pull Request #17955 · bevyengine/bevy

bushrat011899 · 2025-02-20T23:15:40Z

Objective

Fixes Tracking Issue: MVP no_std Bevy #15460 (will open new issues for further no_std efforts)
Supersedes DRAFT: no_std support for bevy and bevy_internal #17715

Solution

Threaded in new features as required
Made certain crates optional but default enabled
Removed compile-check-no-std from internal ci tool since GitHub CI can now simply check bevy itself now
Added CI task to check bevy on thumbv6m-none-eabi to ensure portable-atomic support is still valid ¹

Testing

CI

Release Notes

Bevy now has support for no_std directly from the bevy crate.

Users can disable default features and enable a new default_no_std feature instead, allowing bevy to be used in no_std applications and libraries.

# Bevy for `no_std` platforms
bevy = { version = "0.16", default-features = false, features = ["default_no_std"] }

default_no_std enables certain required features, such as libm and critical-section, and as many optional crates as possible (currently just bevy_state). For atomically-challenged platforms such as the Raspberry Pi Pico, portable-atomic will be used automatically.

For library authors, we recommend depending on bevy with default-features = false to allow std and no_std users to both depend on your crate. Here are some recommended features a library crate may want to expose:

[features]
# Most users will be on a platform which has `std` and can use the more-powerful `async_executor`.
default = ["std", "async_executor"]

# Features for typical platforms.
std = ["bevy/std"]
async_executor = ["bevy/async_executor"]

# Features for `no_std` platforms.
libm = ["bevy/libm"]
critical-section = ["bevy/critical-section"]

[dependencies]
# We disable default features to ensure we don't accidentally enable `std` on `no_std` targets, for example. 
bevy = { version = "0.16", default-features = false }

While this is verbose, it gives the maximum control to end-users to decide how they wish to use Bevy on their platform.

We encourage library authors to experiment with no_std support. For libraries relying exclusively on bevy and no other dependencies, it may be as simple as adding #![no_std] to your lib.rs and exposing features as above! Bevy can also provide many std types, such as HashMap, Mutex, and Instant on all platforms. See bevy::platform_support for details on what's available out of the box!

Migration Guide

If you were previously relying on bevy with default features disabled, you may need to enable the std and async_executor features.
bevy_reflect has had its bevy feature removed. If you were relying on this feature, simply enable smallvec and smol_str instead.

This may be controversial, since it could be interpreted as implying Bevy will maintain support for thumbv6m-none-eabi going forward. In reality, just like x86_64-unknown-none, this is a canary target to make it clear when portable-atomic no longer works as intended (fixing atomic support on atomically challenged platforms). If a PR comes through and makes supporting this class of platforms impossible, then this CI task can be removed. I however wager this won't be a problem. ↩

_Possibly_ controversial, but support _should_ be relatively easy to maintain

bushrat011899 · 2025-02-21T04:23:37Z

I've removed the compile-check-no-std subcommand from the ci tool, since now it is sufficient to just compile bevy itself on a no_std target. I also noticed a regression in platform support that snuck in for thumbv6m-none-eabi. This isn't surprising, since this platform wasn't being checked in CI. I've taken the possibly controversial step of adding it as a CI task. This allows us to test whether the portable-atomic feature actually improves platform compatibility (by allowing atomically challenged platforms to work with Bevy).

The way I see it, this isn't saying "we guarantee Bevy will work on thumbv6m-none-eabi" any more than compile-check-no-std checking against x86_64-unknown-none did for that platform. Really, this is just a target with known characteristics (no_std, and incomplete atomic support) which we can use to know if Bevy is able to maintain support for these platforms or not. If passing this CI task becomes a burden in the future (which I don't believe it will), then it could be removed, along with the portable-atomic feature itself. But again, I don't see that being required without substantial changes to how Bevy currently works.

bushrat011899 · 2025-02-21T04:45:59Z

build-wasm-atomics CI failure will be fixed by #17959. check-advisories appears unrelated and I remember being an issue previously too.

TimJentzsch

Surprisingly straightforward.

It might be useful to add a tiny overview of what isn't available with no_std yet to the release notes.

crates/bevy_reflect/Cargo.toml

bushrat011899 · 2025-02-24T21:10:47Z

With #17570 merging this PR can be simplified (and it wouldn't successfully merge anyway since the portable-atomic feature is now gone)

bushrat011899 · 2025-02-24T21:50:48Z

Ok should be good to go!

alice-i-cecile · 2025-03-06T21:20:33Z

@bushrat011899 cam you get CI green, then bug me for a review and merge? Skimming this it looks fine.

Original implementation uses outdated `futures-lite` version relying on unmaintained `instant`.

bushrat011899 · 2025-03-06T23:23:43Z

@alice-i-cecile Ok so the fix for the check-advisory was a little unfortunate. The problem is bevy_tasks relies on edge-executor for no_std support (most viable drop-in replacement for async-executor I could find). However, it relies on an outdated version of futures-lite which brings in instant. Because the crate hasn't been updated in a year, and I'd really like to get this merged for 0.16, I've vendored in the single file we need for bevy_tasks. I've appropriately attributed to the original author and left a TODO comment indicating we should replace this when/if @NthTensor's Forte is brought into Bevy.

All tests that edge-executor had (including in its separate tests folder) have been inlined as well, so it's no-worse from a maintenance perspective IMO.

alice-i-cecile

That's unfortunate. I think I agree with your choice though, and the rest of this LGTM. Merging.

alice-i-cecile · 2025-03-07T02:08:27Z

@bushrat011899 those CI failures look real <3

bushrat011899 · 2025-03-07T03:21:35Z

Ok so the issue here is we would like bevy to compile without default features, but to add no_std support we need to add 2 pairs of features where one or the other must be enabled:

edge_executor or async_executor for task execution backend
std or libm for floating point maths backend

Since I had to already inline edge_executor, that was easy to resolve, since I can do a negative bound on the async_executor feature to ex/include that module (since almost all of its dependencies were required anyway). For libm/std, I instead made bevy_math, bevy_transform, and bevy_input (the only crates that need a floating point backend selected) optional, enabled by using either std or libm.

This required some light refactoring for the relevant features, but it now means that bevy can be used without default features.

alice-i-cecile · 2025-03-25T20:09:08Z

Thank you to everyone involved with the authoring or reviewing of this PR! This work is relatively important and needs release notes! Head over to bevyengine/bevy-website#2001 if you'd like to help out.

# Objective - Fixes bevyengine#15460 (will open new issues for further `no_std` efforts) - Supersedes bevyengine#17715 ## Solution - Threaded in new features as required - Made certain crates optional but default enabled - Removed `compile-check-no-std` from internal `ci` tool since GitHub CI can now simply check `bevy` itself now - Added CI task to check `bevy` on `thumbv6m-none-eabi` to ensure `portable-atomic` support is still valid [^1] [^1]: This may be controversial, since it could be interpreted as implying Bevy will maintain support for `thumbv6m-none-eabi` going forward. In reality, just like `x86_64-unknown-none`, this is a [canary](https://en.wiktionary.org/wiki/canary_in_a_coal_mine) target to make it clear when `portable-atomic` no longer works as intended (fixing atomic support on atomically challenged platforms). If a PR comes through and makes supporting this class of platforms impossible, then this CI task can be removed. I however wager this won't be a problem. ## Testing - CI --- ## Release Notes Bevy now has support for `no_std` directly from the `bevy` crate. Users can disable default features and enable a new `default_no_std` feature instead, allowing `bevy` to be used in `no_std` applications and libraries. ```toml # Bevy for `no_std` platforms bevy = { version = "0.16", default-features = false, features = ["default_no_std"] } ``` `default_no_std` enables certain required features, such as `libm` and `critical-section`, and as many optional crates as possible (currently just `bevy_state`). For atomically-challenged platforms such as the Raspberry Pi Pico, `portable-atomic` will be used automatically. For library authors, we recommend depending on `bevy` with `default-features = false` to allow `std` and `no_std` users to both depend on your crate. Here are some recommended features a library crate may want to expose: ```toml [features] # Most users will be on a platform which has `std` and can use the more-powerful `async_executor`. default = ["std", "async_executor"] # Features for typical platforms. std = ["bevy/std"] async_executor = ["bevy/async_executor"] # Features for `no_std` platforms. libm = ["bevy/libm"] critical-section = ["bevy/critical-section"] [dependencies] # We disable default features to ensure we don't accidentally enable `std` on `no_std` targets, for example. bevy = { version = "0.16", default-features = false } ``` While this is verbose, it gives the maximum control to end-users to decide how they wish to use Bevy on their platform. We encourage library authors to experiment with `no_std` support. For libraries relying exclusively on `bevy` and no other dependencies, it may be as simple as adding `#![no_std]` to your `lib.rs` and exposing features as above! Bevy can also provide many `std` types, such as `HashMap`, `Mutex`, and `Instant` on all platforms. See `bevy::platform_support` for details on what's available out of the box! ## Migration Guide - If you were previously relying on `bevy` with default features disabled, you may need to enable the `std` and `async_executor` features. - `bevy_reflect` has had its `bevy` feature removed. If you were relying on this feature, simply enable `smallvec` and `smol_str` instead. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

Add no_std support to bevy

f9c57fa

bushrat011899 mentioned this pull request Feb 20, 2025

DRAFT: no_std support for bevy and bevy_internal #17715

Closed

alice-i-cecile added X-Blessed Has a large architectural impact or tradeoffs, but the design has been endorsed by decision makers M-Release-Note Work that should be called out in the blog due to impact and removed X-Uncontroversial This work is generally agreed upon labels Feb 20, 2025

Fix thumbv6m-none-eabi Compatibility and add to CI

8ea1787

_Possibly_ controversial, but support _should_ be relatively easy to maintain

TimJentzsch added the M-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide label Feb 21, 2025

TimJentzsch approved these changes Feb 21, 2025

View reviewed changes

crates/bevy_reflect/Cargo.toml Show resolved Hide resolved

bushrat011899 added 2 commits February 21, 2025 20:13

Merge branch 'main' into NoSTDForBevyItselfV2

1999297

Merge remote-tracking branch 'upstream/main' into NoSTDForBevyItselfV2

3295da6

bushrat011899 added the S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged label Feb 24, 2025

bushrat011899 added 4 commits February 25, 2025 08:16

Merge remote-tracking branch 'upstream/main' into NoSTDForBevyItselfV2

52ee47f

Merge remote-tracking branch 'upstream/main' into NoSTDForBevyItselfV2

9931f17

Simplify features now that portable-atomic is removed

7b49b9c

Update ci.yml

5991069

bushrat011899 removed the S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged label Feb 24, 2025

bushrat011899 added 4 commits February 25, 2025 15:07

Fix bevy_color feature gates

e3ac49d

Formatting

c6c7a60

Merge remote-tracking branch 'upstream/main' into NoSTDForBevyItselfV2

70b6c5b

Fix arbitrary self types issue

0755b51

Merge remote-tracking branch 'upstream/main' into NoSTDForBevyItselfV2

184ef80

alice-i-cecile added this to the 0.16 milestone Mar 4, 2025

Merge branch 'main' into NoSTDForBevyItselfV2

e3262ce

bushrat011899 added 2 commits March 7, 2025 10:14

Inline edge-executor

f5af460

Original implementation uses outdated `futures-lite` version relying on unmaintained `instant`.

cargo fmt

b5d3762

alice-i-cecile approved these changes Mar 7, 2025

View reviewed changes

alice-i-cecile added this pull request to the merge queue Mar 7, 2025

github-merge-queue bot removed this pull request from the merge queue due to failed status checks Mar 7, 2025

bushrat011899 added 3 commits March 7, 2025 14:13

Refactor features to allow --no-default-features to compile

13fabea

Merge remote-tracking branch 'upstream/main' into NoSTDForBevyItselfV2

d032c2e

Update cargo_features.md

3d09e4b

alice-i-cecile approved these changes Mar 7, 2025

View reviewed changes

alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Mar 7, 2025

alice-i-cecile enabled auto-merge March 7, 2025 03:33

alice-i-cecile added this pull request to the merge queue Mar 7, 2025

Merged via the queue into bevyengine:main with commit cc69fdd Mar 7, 2025
36 checks passed

bushrat011899 mentioned this pull request Mar 7, 2025

Support for non-browser wasm #17499

Merged

alexgershberg mentioned this pull request Mar 8, 2025

Project that depends on Bevy with no default features but just feature [std] fails to compile (use of unresolved module or unlinked crate bevy_utils) #18200

Closed

rparrett mentioned this pull request Mar 18, 2025

bevy_input is now optional, but there's no way to enable it #18397

Closed

alice-i-cecile mentioned this pull request Mar 25, 2025

Write release notes for PR #17955: Add no_std support to bevy bevyengine/bevy-website#2001

Closed

Shatur mentioned this pull request Aug 12, 2025

Add no_std support to bevy_log #20539

Draft

Uh oh!

Conversation

bushrat011899 commented Feb 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Objective

Solution

Testing

Release Notes

Migration Guide

Footnotes

Uh oh!

bushrat011899 commented Feb 21, 2025

Uh oh!

bushrat011899 commented Feb 21, 2025

Uh oh!

TimJentzsch left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bushrat011899 commented Feb 24, 2025

Uh oh!

bushrat011899 commented Feb 24, 2025

Uh oh!

alice-i-cecile commented Mar 6, 2025

Uh oh!

bushrat011899 commented Mar 6, 2025

Uh oh!

alice-i-cecile left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alice-i-cecile commented Mar 7, 2025

Uh oh!

bushrat011899 commented Mar 7, 2025

Uh oh!

Uh oh!

alice-i-cecile commented Mar 25, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bushrat011899 commented Feb 20, 2025 •

edited

Loading