Fix compile errors for targets with limited atomic support

[mgood]

Objective

In attempting to update bevy_mod_gba to support newer releases (see bushrat011899/bevy_mod_gba#9) I encountered a few compilation issues due to the lack of atomic support on the "thumb4t" target used by the GBA.

The Rust toolchain basically eliminated atomics support for a few arm/thumb targets due to some limitations: rust-lang/rust#149241

So, with a Rust toolchain newer than 2025-12-02 Bevy has a few new compile issues due to missing atomics.

Solution

In bevy_reflect I added cfg guards to the various atomics based on the appropriate sizes.

For the new AtomicTick type I updated the AtomicU32 import to use the compatiblity imports from bevy_platform which provide a fallback on platforms lacking native atomic support.

Testing

These fixes were sufficient to build and run a simple GBA app, along with using a version of foldhash that includes this patch for atomics support: orlp/foldhash#46

I published a simple demo here which builds a GBA app using this patched version of Bevy: https://github.com/mgood/agb_bevy_demo

(I attempted to just patch bevy_mod_gba but due to some separate issues bringing it up-to-date I started with a much simpler demo app that just has basic graphics and input support)

My build environment is not currently set up to build the whole Bevy suite, so I have some separate compilation issues with the examples failing with errors like this, even on a clean checkout of main:

  = note: ld: warning: ignoring duplicate libraries: '-lSystem', '-lc', '-lobjc'
          ld: warning: object file (...) was built for newer 'macOS' version (27.0) than being linked (11.0)

I have run the tests for bevy_reflect, and I'm attempting to figure out which other broader test targets I can run as well.

cargo test bevy_reflect

[github-actions]

Welcome, new contributor!

Please make sure you've read our contributing guide, as well as our policy regarding AI usage, and we look forward to reviewing your pull request shortly ✨

[mgood]

There's probably a better pattern to use for these checks on the imports, but this was the best I found to avoid either leaving "unused imports" when the implementation isn't used while not hitting errors for the imports being compiled away in other circumstances.

[MrGVSV]

Could we make this apply to the whole module rather than on every import and the macro individually?

[mgood]

Oh yes, thanks I've moved the check.

[MrGVSV]

Assuming target_has_atomic = 8 is a prerequisite for all other atomic sizes, I think we should conditionally compile the entire module with that. Is there any reason not to?

[mgood]

Assuming target_has_atomic = 8 is a prerequisite for all other atomic sizes, I think we should conditionally compile the entire module with that. Is there any reason not to?

Oh yes, that makes sense. I hadn't run into a need to do it at the mod level before, but that's definitely simpler.

[mgood]

These are now redundant with the mod-level check, but I figured this might be clearer for consistency instead of a comment or something about why they're not needed at this level.

[mgood]

Oh yes, thanks I've moved the check.

[mgood]

I just realized I had overlooked issue #25205 which reported the bevy_reflect errors, though they also note an issue with dependencies of bevy_tasks requiring

futures-core = { version = "*", default-features = false, features = ["portable-atomic"] }

With 0.20-dev enabling default_no_std I get a different error:

cargo build
   Compiling portable-atomic v1.15.0
error: you may not enable `critical-section` feature and `portable_atomic_unsafe_assume_{single_core,privileged}` cfg (`unsafe-assume-{single-core,privileged}` feature) at the same time
   --> /Users/matt/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/portable-atomic-1.15.0/src/lib.rs:582:1
    |
582 | / compile_error!(
583 | |     "you may not enable `critical-section` feature and `portabl...
584 | | );
    | |_^

error: could not compile `portable-atomic` (lib) due to 1 previous error

Just enabling the other features besides critical-section from default_no_std ("libm", "bevy_color", "bevy_state") compiles. So, it seems like this PR mainly fixes #25205, though including critical-section in default_no_std doesn't seem to work on at least some no_std targets. Though I don't know which others may need that.

[alice-i-cecile]

Yep, happy to review more PRs like this as you need them :) We don't have a ton of users working on embedded, so efforts to fight entropy like this are lovely.