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.