Add no_std support to bevy

[bushrat011899]

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. However, note that certain features are required for Bevy to compile. Below is a table to help understand some of these new features relating to platform compatibility. Note that ✔️ indicates a feature is required for a particular target, ❌ indicates a feature is incompatible, and ➖ indicates a feature can be used with that platform.

Feature	std (e.g., x86_64-pc-windows-msvc for Windows)	no_std (e.g., x86_64-unknown-none)
std	➖	❌
async_executor2	➖	❌
edge_executor2	➖	✔️
libm3	➖	✔️
critical-section	➖	✔️

This table may still be confusing, so 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.
edge_executor = ["bevy/edge_executor"]
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. For example, edge_executor is included for no_std support, but users may still choose to use it on std targets. Making that assumption on behalf of the user takes that control away from them.

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.

Footnotes

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 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. ↩

2. Note that either async_executor or edge_executor must be enabled for compilation to succeed. This is a tradeoff to reduce the number of dependencies included in typical std builds (where async_executor was already being used). In the future this may change in refactors of bevy_tasks. Watch this space! ↩ ↩²

3. libm is actually quite desirable on std targets anyway, since it has better cross-platform determinism, making it better suited for multiplayer games. On no_std it becomes required, since certain maths operations are only available from std and not in core. ↩

[bushrat011899]

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]

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.

[bushrat011899]

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

[bushrat011899]

Ok should be good to go!