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

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

[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!

[alice-i-cecile]

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

[bushrat011899]

@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]

@bushrat011899 those CI failures look real <3

[bushrat011899]

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]

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.