Add no_std Support to bevy_math

[bushrat011899]

Objective

• Contributes to Tracking Issue: MVP no_std Bevy #15460

Solution

• Added two new features, std (default) and alloc, gating std and alloc behind them respectively.
• Added missing f32 functions to std_ops as required. These f32 methods have been added to the clippy.toml deny list to aid in no_std development.

Testing

• CI
• cargo clippy -p bevy_math --no-default-features --features libm --target "x86_64-unknown-none"
• cargo test -p bevy_math --no-default-features --features libm
• cargo test -p bevy_math --no-default-features --features "libm, alloc"
• cargo test -p bevy_math --no-default-features --features "libm, alloc, std"
• cargo test -p bevy_math --no-default-features --features "std"

Notes

The following items require the alloc feature to be enabled:

• CubicBSpline
• CubicBezier
• CubicCardinalSpline
• CubicCurve
• CubicGenerator
• CubicHermite
• CubicNurbs
• CyclicCubicGenerator
• RationalCurve
• RationalGenerator
• BoxedPolygon
• BoxedPolyline2d
• BoxedPolyline3d
• SampleCurve
• SampleAutoCurve
• UnevenSampleCurve
• UnevenSampleAutoCurve
• EvenCore
• UnevenCore
• ChunkedUnevenCore

This requirement could be relaxed in certain cases, but I had erred on the side of gating rather than modifying. Since no_std is a new set of platforms we are adding support to, and the alloc feature is enabled by default, this is not a breaking change.

[mweatherley]

A few notes:

1. The purpose of the ops module is (or perhaps was) to guarantee that alternatives to std floating-point functions with unspecified precision were available, in the interest of cross-platform determinism. Since libm is no_std-compatible, I think this extension of that is pretty reasonable, but this is a break from its original purpose.

2. I have concerns about the ongoing maintenance burden of these changes. For example, we lint against std math operations with unspecified precision for the aforementioned determinism reasons; right now, as far as I'm aware, this doesn't extend to the new methods added, so I'm not sure if breaks to no_std compatibility are actually discoverable.

3. cubic_splines is feature-gated behind alloc, but plenty of other areas use alloc as well. What is the logic behind this?

[bushrat011899]

1. The purpose of the ops module is (or perhaps was) to guarantee that alternatives to std floating-point functions with unspecified precision were available, in the interest of cross-platform determinism. Since libm is no_std-compatible, I think this extension of that is pretty reasonable, but this is a break from its original purpose.

That makes sense, thanks for clarifying the original intent of the module for me! I think to highlight this change in intent I'll update the module documentation to say there are two reasons you'd want to use std_ops: determinism, and no_std compatibility.

2. I have concerns about the ongoing maintenance burden of these changes. For example, we lint against std math operations with unspecified precision for the aforementioned determinism reasons; right now, as far as I'm aware, this doesn't extend to the new methods added, so I'm not sure if breaks to no_std compatibility are actually discoverable.

I'll look into adding these new methods to the lint as well, with some documentation explaining that it's for no_std compatibility. It's not included in this PR, but my intention is to add no_std testing to the CI as well. Right now it's sufficient to attempt compilation for a no_std target (e.g., x86_64-unknown-none), but this is still an open question (which no_std platforms are people actually using Bevy on in this hypothetical future? Bare metal x86 is an example, but perhaps not realistic)

3. cubic_splines is feature-gated behind alloc, but plenty of other areas use alloc as well. What is the logic behind this?

My reasoning here was I saw a large amount of alloc usage contained within this module, so I feature gated the whole lot. I will look into it more closely to see if there are some elements which can still be exported without alloc, and if so, move the feature gate inside the module.

[bushrat011899]

Added to the 0.16 milestone to indicate this is not intended to be merged during the 0.15 release cycle.

[Jondolf]

This does increase maintenance burden somewhat / make some things slightly uglier, but I would say it's worth it for no_std support, and to move the no_std efforts as a whole forward. Changes look good to me, didn't notice anything wrong.

[mweatherley]

Just one thing that I found kind of confusing at first glance.

My main concern with this is just making sure that we have enough tools (in CI or otherwise) to maintain this matrix of features without breaking compilation in some combination.

[bushrat011899]

My main concern with this is just making sure that we have enough tools (in CI or otherwise) to maintain this matrix of features without breaking compilation in some combination.

Agreed. I've added bevy_math to compile-check-no-std in CI, so the specific feature combination of --no-default-features and --feature libm will be checked, along with the standard set of features in the rest of CI. I do agree that there is a flag combinatorics problem here that no_std exacerbates.