Initial implementation of `core_float_math` #138087

tgross35 · 2025-03-06T06:34:53Z

Since 1, compiler-builtins makes a certain set of math symbols
weakly available on all platforms. This means we can begin exposing some
of the related functions in core, so begin this process here.

It is not possible to provide inherent methods in both core and std
while giving them different stability gates, so standalone functions are
added instead. This provides a way to experiment with the functionality
while unstable; once it is time to stabilize, they can be converted to
inherent.

For f16 and f128, everything is unstable so we can move the inherent
methods.

The following are included to start:

floor
ceil
round
round_ties_even
trunc
fract
mul_add
div_euclid
rem_euclid
powi
sqrt
abs_sub
cbrt

These mirror the set of functions that we have in compiler-builtins
since 1, with the exception of powi that has been there longer.

Details for each of the changes is in the commit messages.

Tracking issue: #137578

try-job: aarch64-gnu
tru-job: armhf-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2

Initial implementation of `core_float_math` Since [1], `compiler-builtins` makes a certain set of math symbols weakly available on all platforms. This means we can begin exposing some of the related functions in `core`, so begin this process here. It is not possible to provide inherent methods in both `core` and `std` while giving them different stability gates, so standalone functions are added instead. This provides a way to experiment with the functionality while unstable; once it is time to stabilize, they can be converted to inherent. For `f16` and `f128`, everything is unstable so we can move the inherent methods. The following are included to start: * floor * ceil * round * round_ties_even * trunc * fract * mul_add * div_euclid * rem_euclid * powi * sqrt * abs_sub * cbrt These mirror the set of functions that we have in `compiler-builtins` since [1]. Tracking issue: rust-lang#137578 [1]: rust-lang/compiler-builtins#763 r? `@ghost` try-job: aarch64-gnu try-job: arm-android tru-job: armhf-gnu try-job: test-various try-job: x86_64-apple-1 try-job: aarch64-apple try-job: i686-msvc-1 try-job: x86_64-msvc-ext2

Initial implementation of `core_float_math` Since [1], `compiler-builtins` makes a certain set of math symbols weakly available on all platforms. This means we can begin exposing some of the related functions in `core`, so begin this process here. It is not possible to provide inherent methods in both `core` and `std` while giving them different stability gates, so standalone functions are added instead. This provides a way to experiment with the functionality while unstable; once it is time to stabilize, they can be converted to inherent. For `f16` and `f128`, everything is unstable so we can move the inherent methods. The following are included to start: * floor * ceil * round * round_ties_even * trunc * fract * mul_add * div_euclid * rem_euclid * powi * sqrt * abs_sub * cbrt These mirror the set of functions that we have in `compiler-builtins` since [1]. Tracking issue: rust-lang#137578 [1]: rust-lang/compiler-builtins#763 r? `@ghost` try-job: aarch64-apple try-job: aarch64-gnu try-job: arm-android tru-job: armhf-gnu try-job: dist-various-1 try-job: dist-various-2 try-job: i686-msvc-1 try-job: test-various try-job: x86_64-apple-1 try-job: x86_64-msvc-ext2

Initial implementation of `core_float_math` Since [1], `compiler-builtins` makes a certain set of math symbols weakly available on all platforms. This means we can begin exposing some of the related functions in `core`, so begin this process here. It is not possible to provide inherent methods in both `core` and `std` while giving them different stability gates, so standalone functions are added instead. This provides a way to experiment with the functionality while unstable; once it is time to stabilize, they can be converted to inherent. For `f16` and `f128`, everything is unstable so we can move the inherent methods. The following are included to start: * floor * ceil * round * round_ties_even * trunc * fract * mul_add * div_euclid * rem_euclid * powi * sqrt * abs_sub * cbrt These mirror the set of functions that we have in `compiler-builtins` since [1], with the exception of `powi` that has been there longer. Tracking issue: rust-lang#137578 [1]: rust-lang/compiler-builtins#763 r? `@ghost` try-job: aarch64-apple try-job: aarch64-gnu try-job: arm-android tru-job: armhf-gnu try-job: dist-various-1 try-job: dist-various-2 try-job: i686-msvc-1 try-job: test-various try-job: x86_64-apple-1 try-job: x86_64-msvc-ext2

tgross35 · 2025-03-06T21:35:19Z

test-various passed, the others likely only need tweaks for f128 config.

r? @Amanieu

DJMcNab · 2025-05-19T06:15:43Z

This landing in nightly has unfortunately broken Linebender's color crate. This is because we are trying to access the cbrt method on type@f32 as f32::cbrt (defined via a trait which uses libm to polyfill), and separately incidentally import the core::f32 module (presumably for some constants - I'm on mobile so can't check).

Name resolution seems to prefer these new functions over the ones defined on the f32 type. Unfortunately, as far as I know, there is no fully qualified name for f32, so we have to tweak our code to either define a type alias for f32, or to not import core::f32

I'm not sure how to determine if this class of breakage is classed as allowable. I think it would in theory be a regression on stable once 1.89 is stable. However, no matter where these functions live, it would be possible to adversarially trigger this for any unstable function being added.
I also don't really see what the alternative on the libs team side could be.

tgross35 · 2025-05-19T07:26:54Z

Are you glob importing something from std? This is something we do try to discourage because that means that std adding any new api can break things (rust-lang/rust-clippy#13961). Regardless of the outcome here, please consider fixing this in color.

However, this is also intended to be temporary API that isn’t worth breaking anybody over, and color is a large enough crate to justify reconsideration. I think it would be fine if you put up a PR moving these from core::f32 to a new core::f32::math, unless @Amanieu has any thoughts here. (If you don’t get to it, I should be able to later)

ajakubowicz-canva · 2025-05-19T07:35:21Z

For reference – fix for color: linebender/color#175

beetrees · 2025-05-19T07:57:33Z

Unfortunately, as far as I know, there is no fully qualified name for f32

For reference, all the primitive types are re-exported in std::primitive/core::primitive.

DJMcNab · 2025-05-19T08:33:14Z

Are you glob importing something from std?

No, not that I'm aware of. We're only importing the (module) core::f32, and separately attempting to get a function value for the f32::cbrt function, to (edit: use it in an iterator map).
This is morally the "adding a new inherent method" breakage, but it occurs due to core::f32 and type@f32 having the same name.

We have now made a remedial release of color (I don't know if this impacts prior minor versions - I'm still on mobile).

Amanieu · 2025-05-19T09:47:24Z

It's hard to evaluate the breakage without the crater run, so we should either:

Revert this and perform a crater run.
Just move these to a different module like core::f32::math.

When these functions were added in rust-lang#138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute. We ran into this in Color - https://github.com/linebender/color - and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`. As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this breakage doesn't adversely impact anyone else.

…ross35 `core_float_math`: Move functions to `math` module When these functions were added in rust-lang#138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over the `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute. We ran into this in [Color](https://github.com/linebender/color) and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`. As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this "breakage" doesn't adversely impact anyone else. I believe that I've made the module unstable correctly. I presume that this does not require a test to make sure stable code can't depend on the module existing? I've left the stability attribute on each function - happy to tweak this if a different pattern is more correct. Tracking issue for `core_float_math`: rust-lang#137578. This PR is as requested in rust-lang#138087. r? `@tgross35` Recommended reviewing with whitespace hidden. (This is my first PR to `std/core`/this repository, as far as I can remember)

tgross35 · 2025-05-20T20:37:48Z

No, not that I'm aware of. We're only importing the (module) core::f32, and separately attempting to get a function value for the f32::cbrt function, to.
This is morally the "adding a new inherent method" breakage, but it occurs due to core::f32 and type@f32 having the same name.

Thanks for clarifying, that is an unusual case.

Just move these to a different module like core::f32::math.

The new module seems easier than bothering to evaluate breakage, especially since this is destined to get deleted anyway. #141282 moves them.

Rollup merge of rust-lang#141282 - DJMcNab:core-float-math-math, r=tgross35 `core_float_math`: Move functions to `math` module When these functions were added in rust-lang#138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over the `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute. We ran into this in [Color](https://github.com/linebender/color) and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`. As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this "breakage" doesn't adversely impact anyone else. I believe that I've made the module unstable correctly. I presume that this does not require a test to make sure stable code can't depend on the module existing? I've left the stability attribute on each function - happy to tweak this if a different pattern is more correct. Tracking issue for `core_float_math`: rust-lang#137578. This PR is as requested in rust-lang#138087. r? `@tgross35` Recommended reviewing with whitespace hidden. (This is my first PR to `std/core`/this repository, as far as I can remember)

Initial implementation of `core_float_math` Since [1], `compiler-builtins` makes a certain set of math symbols weakly available on all platforms. This means we can begin exposing some of the related functions in `core`, so begin this process here. It is not possible to provide inherent methods in both `core` and `std` while giving them different stability gates, so standalone functions are added instead. This provides a way to experiment with the functionality while unstable; once it is time to stabilize, they can be converted to inherent. For `f16` and `f128`, everything is unstable so we can move the inherent methods. The following are included to start: * floor * ceil * round * round_ties_even * trunc * fract * mul_add * div_euclid * rem_euclid * powi * sqrt * abs_sub * cbrt These mirror the set of functions that we have in `compiler-builtins` since [1], with the exception of `powi` that has been there longer. Details for each of the changes is in the commit messages. Tracking issue: rust-lang#137578 [1]: rust-lang/compiler-builtins#763 try-job: aarch64-gnu tru-job: armhf-gnu try-job: i686-msvc-1 try-job: test-various try-job: x86_64-mingw-1 try-job: x86_64-mingw-2

When these functions were added in rust-lang#138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute. We ran into this in Color - https://github.com/linebender/color - and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`. As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this breakage doesn't adversely impact anyone else.

…ross35 `core_float_math`: Move functions to `math` module When these functions were added in rust-lang#138087 It made a relatively common pattern for emulating these functions using an extension trait (which internally uses `libm`) much more fragile. If `core::f32` happened to be imported by the user (to access a constant, say), then that import in the module namespace would take precedence over the `f32` in the type namespace for resolving these functions, running headfirst into the stability attribute. We ran into this in [Color](https://github.com/linebender/color) and chose to release the remedial 0.3.1 and 0.2.4, to allow downstream crates to build on `docs.rs`. As these methods are perma-unstable, moving them into a new module should not have any long-term concerns, and ensures that this "breakage" doesn't adversely impact anyone else. I believe that I've made the module unstable correctly. I presume that this does not require a test to make sure stable code can't depend on the module existing? I've left the stability attribute on each function - happy to tweak this if a different pattern is more correct. Tracking issue for `core_float_math`: rust-lang#137578. This PR is as requested in rust-lang#138087. r? `@tgross35` Recommended reviewing with whitespace hidden. (This is my first PR to `std/core`/this repository, as far as I can remember)

As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: rust-lang#138087 (comment)

float: Replace some approximate assertions with exact As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: #138087 (comment) The first commit is a small bit of macro cleanup. try-job: aarch64-gnu

As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: rust-lang#138087 (comment)

float: Replace some approximate assertions with exact As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: #138087 (comment) The first commit is a small bit of macro cleanup. try-job: aarch64-gnu try-job: gnu-aux

float: Replace some approximate assertions with exact As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: #138087 (comment) The first commit is a small bit of macro cleanup. try-job: aarch64-gnu try-job: x86_64-gnu-aux

As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: rust-lang#138087 (comment)

…fJung float: Replace some approximate assertions with exact As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: rust-lang#138087 (comment) The first commit is a small bit of macro cleanup. try-job: aarch64-gnu try-job: x86_64-gnu-aux

Rollup merge of #141669 - tgross35:float-test-cleanup, r=RalfJung float: Replace some approximate assertions with exact As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: #138087 (comment) The first commit is a small bit of macro cleanup. try-job: aarch64-gnu try-job: x86_64-gnu-aux

float: Replace some approximate assertions with exact As was mentioned at [1], we currently use `assert_approx_eq` for testing some math functions that guarantee exact results. Replace approximate assertions with exact ones for the following: * `ceil` * `floor` * `fract` * `from_bits` * `mul_add` * `round_ties_even` * `round` * `trunc` This likely wasn't done in the past to avoid writing out exact decimals that don't match the intuitive answer (e.g. 1.3 - 1.0 = 0.300...004), but ensuring our results are accurate seems more important here. [1]: rust-lang/rust#138087 (comment) The first commit is a small bit of macro cleanup. try-job: aarch64-gnu try-job: x86_64-gnu-aux

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 6, 2025

This comment has been minimized.

Sign in to view

tgross35 force-pushed the core-float-math branch from 9cc8ffd to b74488e Compare March 6, 2025 07:21