Tracking Issue: MVP no_std Bevy

[bushrat011899]

This is a tracking issue for progress on a no_std compatible subset of Bevy. The tasks are ordered roughly in sequence (bevy_app can't be no_std until bevy_ecs is for example).

Core Tasks

These tasks must be completed for a no_std Bevy to become usable at all.

• Turn on lints encouraging the use of core and alloc instead of std
  Add core and alloc over std Lints #15281
• bevy_ptr
• bevy_utils
  Minor fixes for bevy_utils in no_std #15463
  • Provide an appropriate Instant type which can be controlled by the user in no_std contexts, or avoid its use
  • Move web-time into wasm32-only dependencies (doesn't need to exist outside web anyway!)
  • Make thread_local optional
• bevy_tasks
  Add no_std support to bevy_tasks #15464
  • Replace async-executor with a no_std compatible executor
    Can just be a direct copy of the existing Local/Executor using no_std compatible types from a crate like spin
  • Add std/alloc features
• bevy_macro_utils
  Modify derive_label to support no_std environments #15465
  • Update derive_label to use Box from alloc
    (requires wrapping the quoted impl in a const _: () = { ... } so that extern crate alloc wont conflict with the outer namespace)
• bevy_ecs
  • Replace petgraph's GraphMap
    Remove petgraph from bevy_ecs #15519
    A direct copy does work since the biggest issue is the complex trait network petgraph uses and their reliance on the std feature of indexmap, which we don't need.
  • Replace petgraph's TarjanScc
    Remove petgraph from bevy_ecs #15519
    A direct copy is also possible here.
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_ecs #15774
  • Add std/alloc features
• bevy_app
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_app #15779
  • Add std/alloc features
• bevy_internal / bevy
  • Thread std / alloc features from sub-crates through to the final bevy crate.
    Will require making most extra Bevy crates optional behind a std feature. However, as more crates are made no_std these can be moved out from that feature gate.
• Update CI to ensure no_std compatibility is preserved
  Add compile-check-no-std Command to CI Tool #15843

Bonus Features

These tasks aren't strictly required, but should be completed to close the gap between no_std and std Bevy. The more functionality we can provide in no_std, the more the community can develop for it.

• bevy_animation
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_animation #15780
  • Replace petgraph with a no_std compatible alternative.
    Currently only using the DiGraph type with no edge data and only a single node type AnimationGraphNode (and a serializable alternate SerializedAnimationGraphNode).
• bevy_asset
  Reliance on filesystem operations will make this interesting, but a lot of the asset functionality exists outside of files and folders (processing, etc.).
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_asset #15778
• bevy_color
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_color #15777
• bevy_core
• bevy_derive
• bevy_diagnostic
• bevy_hierarchy
• bevy_image
  Remove thiserror from bevy_image #15771
• bevy_input
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_input #15770
• bevy_log
• bevy_math
  Add no_std Support to bevy_math #15810
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_math #15769
• bevy_mesh
  Remove thiserror from bevy_mesh #15768
• bevy_mikktspace
  Add no_std support to bevy_mikktspace #15528
• bevy_reflect
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_reflect #15766
• bevy_remote
  Might be able to work over serial?
• bevy_state
• bevy_time
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_time #15759
• bevy_transform
  • Replace thiserror with a no_std compatible alternative.
    Remove thiserror from bevy_transform #15761

Not Planned

These crates can't be ported to no_std because they are highly platform specific. If you see something on this list that could be ported, please let me know!

• bevy_a11y
• bevy_audio
• bevy_core_pipeline
  Remove thiserror from bevy_core_pipeline #15775
• bevy_dev_tools
• bevy_dylib
• bevy_encase_derive
• bevy_gilrs
  Remove thiserror from bevy_gilrs #15773
• bevy_gizmos
• bevy_gltf
  Remove thiserror from bevy_gltf #15772
• bevy_pbr
  Remove thiserror from bevy_pbr #15767
• bevy_render
  Remove thiserror from bevy_render #15765
• bevy_scene
  Remove thiserror from bevy_scene #15764
• bevy_sprite
  Remove thiserror from bevy_sprite #15763
• bevy_text
  Remove thiserror from bevy_text #15762
• bevy_ui
  Remove thiserror from bevy_ui #15760
• bevy_window
• bevy_winit

General Notes

thiserror

thiserror is currently not available in a no_std form due to its use of the ::std::error::Error path for Error (which it continues to use for MSRV backwards compatibility). There is a PR to add no_std support to thiserror which preserves that MSRV requirement, but it's unclear if/when that will be merged and released.

One alternative is to link against the PR instead of the published version of thiserror:

thiserror = {
  git = "https://github.com/quartiq/thiserror",
  rev = "515bd36da54dbc346250026ddc349c88851e4bb1",
  default-features = false,
}

Another alternative is to switch to using derive_more. This would require adding explicit calls to derive(From, Display) as well, which adds to the noise. Additionally, it isn't already in the dependency tree, so its inclusion may be contentious.

Due to delays in thiserror's no_std support, we have decided to use derive_more.

Platform Support

Being no_std is necessary for certain platforms, but it is not always sufficient. Below is a table of platforms that I have tested:

Name	Target	Builds	Notes
UEFI	x86_64-unknown-uefi	Compiles	Boots on emulated and real hardware, supported by the uefi crate.
GameBoy Advance	thumbv4t-none-eabi	Partially	The platform does not support all atomic operations (e.g., CAS), which Bevy directly and transiently relies on. Moving from tracing to log, and using portable_atomics is sufficient to make this platform compile.
Nintendo Switch	aarch64-nintendo-switch-freestanding	Compiles	I cannot test the binary produced by cargo nx on real hardware or an emulator to confirm it actually works.
PlayStation One	mipsel-sony-psx	Partially	The platform does not support all atomic operations (e.g., CAS), which Bevy directly and transiently relies on. Moving from tracing to log, and using portable_atomics is sufficient to make this platform compile.
MSP430	msp430-none-elf	No	This platform is 16-bit, which breaks too many assumptions made by dependencies like zerocopy.

I have a prototype of no_std compatible Bevy available on this branch. It's not being actively maintained, as it is a proof of concept for upstream no_std support (use at your own risk, etc.). However, if anyone has a particular platform they'd like to use Bevy on, please feel free to test using this branch and let me know what kind of compatibility you have. In general:

• You must be able to compile a Rust project for this platform. (I hope this goes without saying!)
• You must have alloc and core available.
• Your platform must support Atomic CAS (hoping to relax this in the future!)
• Only the bevy_app, bevy_ecs, bevy_utils, and bevy_tasks are compatible in this branch, and must be imported directly (e.g., you can't use bevy;, instead use bevy_app;). Additionally, you must disable default features for no_std compatibility.
• Your platform must be 32-bit or higher due to safety concerns in bevy_ecs. For further information, see [Merged by Bors] - Fail to compile on 16-bit platforms #4736.

[BD103]

Looks like there is some effort to make thiserror support #![no_std] in dtolnay/thiserror#304. Looks like it's on hold until the author responds, though.

[bushrat011899]

Yeah that's where I got the (temporary) fix from:

thiserror = {
  git = "https://github.com/quartiq/thiserror",
  rev = "515bd36da54dbc346250026ddc349c88851e4bb1",
  default-features = false,
}

I'm hoping the PR is merged sooner rather than later, but there's a similar issue with petgraph where there does exist a no_std compatible version, but it's waiting in the wings.

In both cases we have options for how to proceed. Either waiting for those crates to get updated, replacing them with something equivalent, or developing a replacement based on these prior efforts.

[bushrat011899]

After some discussion on the Discord, I'm going to open PRs to replace thiserror with derive_more for at least bevy_ecs and bevy_app in the near-term. A quick experiment on bevy_ecs made the change look pretty minor, and the crate does offer more functionality than thiserror does on its own.

[alice-i-cecile]

Can cargo-deny work on "our" dependencies only? If so, please add a line for thiserror, since derive-more tackles everything we need.

[bushrat011899]

Can cargo-deny work on "our" dependencies only? If so, please add a line for thiserror, since derive-more tackles everything we need.

Unfortunately no. Currently cargo deny treats direct and transitive dependencies identically. We could make a CI job that uses a crate like toml to check if thiserror is present in the dependency table for each Cargo.toml in the crates folder. I suspect we would want to do something like this anyway as a part of a broader no_std CI task.

In the interim, if a user adds thiserror back into Bevy inadvertently we at least have derive_more in-tree ready to go to fix it.