feat: add `const` support for float rounding methods #141521

ruancomelli · 2025-05-24T20:42:42Z

Add `const` support for float rounding methods

This PR makes the following float rounding methods const:

f64::{floor, ceil, trunc, round, round_ties_even}
and the corresponding methods for f16, f32 and f128

Procedure

I followed c09ed3e as closely as I could in making float methods const, and also received great guidance from https://internals.rust-lang.org/t/const-rounding-methods-in-float-types/22957/3?u=ruancomelli.

Question regarding the "unstability" attributes

I did my best to apply the appropriate const stability attributes, but I would greatly appreciate feedback or corrections:

#[rustc_allow_const_fn_unstable(core_intrinsics)] in library/core/src/intrinsics/mod.rs
#[rustc_const_unstable(feature = "f16", issue = "116909")] in library/core/src/num/f16.rs
#[rustc_const_unstable(feature = "f128", issue = "116909")] in library/core/src/num/f128.rs
#[rustc_const_unstable(feature = "const_float_methods", issue = "130843")] in library/core/src/num/32.rs and library/core/src/num/f64.rs

Please let me know if any of these are incorrect or should be revised.

Alternative implementation

I implemented one intrinsic method (float_<...>_intrinsic) for each one of the rounding methods considered in this PR (floor, ceil, trunc, round and round_ties_even). This is similar to how other intrinsics are implemented in compiler/rustc_const_eval/src/interpret/intrinsics.rs.

However, I could have implemented a single one taking a rustc_apfloat::Round parameter:

    fn float_round_intrinsic<F>(
        &mut self,
        args: &[OpTy<'tcx, M::Provenance>],
        dest: &MPlaceTy<'tcx, M::Provenance>,
        mode: rustc_apfloat::Round
    ) -> InterpResult<'tcx, ()>
    where
        F: rustc_apfloat::Float + rustc_apfloat::FloatConvert<F> + Into<Scalar<M::Provenance>>,
    {
        let x: F = self.read_scalar(&args[0])?.to_float()?;
        let res = x.round_to_integral(mode).value;
        self.write_scalar(res, dest)?;
        interp_ok(())
    }

This is, of course, shorter than the current implementation. I'd be happy to change to this version if preferred.

Note

This is my first code contribution to the Rust project, so please let me know if I missed anything - I'd be more than happy to revise and learn more. Thank you for taking the time to review it!

rustbot · 2025-05-24T20:42:46Z

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-05-24T20:42:48Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

RalfJung · 2025-05-24T20:58:56Z

However, I could have implemented a single one taking a rustc_apfloat::Round parameter:

Yes, that's a lot better I think. :)

RalfJung · 2025-05-24T21:17:46Z

Note that your branch has conflicts with the master branch. Not sure how that happened given that the PR is fresh, but it means you'll have to rebase and resolve those conflicts.

ruancomelli · 2025-05-24T23:23:40Z

Strange, CI is failing with intrinsic is not supported at compile-time for each one of the new methods.
I'm looking into that.

ruancomelli · 2025-05-25T00:24:36Z

As far as I can see, the main difference between the newly const methods (e.g. floor) and the ones that already work (e.g. abs) is the attributes. So my current hypothesis is that I got them wrong.

CAD97

AIUI, the reason you're hitting "intrinsic not supported at compile time" is that std currently gets built with the bootstrap compiler, which is then used when building the new compiler. So you need to have a #[cfg(bootstrap)] version of the function/intrinsic which isn't const and a #[cfg(not(bootstrap))] which is.

IIUC, we're in the process of flipping this so that the compiler gets built with the bootstrap std, and std always gets built with the new compiler. Once that switch happens, this won't be necessary anymore.

library/core/src/intrinsics/mod.rs

library/core/src/num/f32.rs

library/std/src/f64.rs

RalfJung · 2025-05-25T07:18:14Z

AIUI, the reason you're hitting "intrinsic not supported at compile time" is that std currently gets built with the bootstrap compiler, which is then used when building the new compiler. So you need to have a #[cfg(bootstrap)] version of the function/intrinsic which isn't const and a #[cfg(not(bootstrap))] which is.

The problem occurs when building the tests. So you don't need to do any cfg in libcore itself, but the new tests in library/coretests need a #[cfg(not(bootstrap))].

library/coretests/tests/num/mod.rs

tests/ui/consts/const-eval/float_methods.rs

RalfJung · 2025-05-25T14:32:39Z

Your functions are not meant to be stable, right? So do the part under "help: if the function is not (yet) meant to be exposed to stable". The other part explicitly says "as a last resort" and "requires team approval"... I don't know how much more scary we have to make that message to stop people from using the attribute. :( Maybe we should just stop mentioning it entirely.

ruancomelli · 2025-05-25T17:23:35Z

Hey @RalfJung and @CAD97, I've addressed or replied to all of your review comments.

I've also created a tracking issue for this feature here: #141555.

I have two main open questions now.

First one is: should the rounding methods on f16 and f128 be gated behind #[rustc_const_unstable(feature = {"f16", "f128"}, issue = "116909")] (from #116909) or #[rustc_const_unstable(feature = "const_float_round_methods", issue = "141555")]? I think it should be the former one, but I'm not sure.

The second question: I added #![feature(const_float_round_methods)] to library/std/src/lib.rs, which was suggested by the compiler itself. Without it, ./x check results in the following errors:

error: `core::f32::math::floor` is not yet stable as a const fn
  --> library/std/src/f32.rs:50:9
   |
50 |         core::f32::math::floor(self)
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
help: add `#![feature(const_float_round_methods)]` to the crate attributes to enable
  --> library/std/src/lib.rs:433:1
   |
433+ #![feature(const_float_round_methods)]
   |

... and similar for the other rounding methods

error: could not compile `std` (lib) due to 12 previous errors

This is similar to what was done in the reference PR, even though they changed library/core/src/lib.rs (notice core and not std).
However, I'm not sure if this is the correct way to proceed. I read the dev guide book, but that question remained unanswered.

library/coretests/tests/num/mod.rs

RalfJung · 2025-05-25T20:45:40Z

First one is: should the rounding methods on f16 and f128 be gated behind #[rustc_const_unstable(feature = {"f16", "f128"}, issue = "116909")] (from #116909) or #[rustc_const_unstable(feature = "const_float_round_methods", issue = "141555")]? I think it should be the former one, but I'm not sure.

Good question! The typical thing we do is to gate it behind the f16/f128 feature, but then also have a second commented out more specific feature gate:

#[rustc_const_unstable(feature = "f16", issue = "116909")]
// #[rustc_const_unstable(feature = "const_float_round_methods", issue = "141555")]
pub const fn trunc(self) -> self { ... }

The second question: I added #![feature(const_float_round_methods)] to library/std/src/lib.rs, which was suggested by the compiler itself.

Yes, that's fine.
Thanks for asking for confirmation. :)

RalfJung · 2025-05-25T20:46:15Z

@rustbot author

rustbot · 2025-05-25T20:46:18Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

RalfJung · 2025-05-26T06:54:40Z

library/coretests/tests/num/mod.rs

@@ -924,6 +924,96 @@ macro_rules! test_float {
                assert!($inf.div_euclid($nan).is_nan());
                assert!($nan.div_euclid($inf).is_nan());
            }
+            #[test]
+            #[cfg(not(bootstrap))]
+            fn floor() {


FWIW we already have floor tests in library/coretests/tests/floats/f*.rs (and same for the other rounding methods). We probably shouldn't duplicate tests, but also those tests can't easily access the "test the same thing in const and regular fn" infrastructure that we have here.

@tgross35 how would you like these tests to be organized? Is it okay to move them from tests/float/f*.rs to here?

It's honestly kind of strange to have float tests in num at all given that the core::num module hardly has any float stuff... but it is described as being for "numeric" types, not just integers. Also this is the wrong PR to move everything around.^^

We probably shouldn't duplicate tests, but also those tests can't easily access the "test the same thing in const and regular fn" infrastructure that we have here.

But the "test the same thing in const and regular" infrastructure is only used for the float tests, so we could move this infra into library/coretests/tests/floats, could we not?

Also this is the wrong PR to move everything around.

Phew! 😄

@tgross35 how would you like these tests to be organized? Is it okay to move them from tests/float/f*.rs to here?

I think that's probably fine in general if needed, but things are bound to get a bit tricky. The f18/f128 functions here need cfg(target_has_reliable_f16_math) gating as well as cfg(miri) since that isn't implemented yet. There are also a few cases where the different sizes need different results (maybe not relevant here?).

As a thought, what if coretests/tests/floats/mod.rs (or coretests/tests/num.rs, whatever) defined macros that expand to test cases, rather than entire tests? So each float type defines its own test functions that can include type-specific tests, but some of the copy+paste and other redundancy is gone.

E.g.:

// coretests/tests/floats/f32.rs #[test] fn test_fract() { shared_fract_tests!(f32); // tests used by all sizes assert_eq!(f32::math::fract(1.3f32), 0.29999995f32); // type-specific tests }

Separately, it seems like it would be useful to have a #[test_const] proc macro that duplicates the test and wraps it in a const block with redefined assert* macros. Since there are a growing number of cases where we want to be able to verify behavior both at CTFE and at runtime.

But the "test the same thing in const and regular" infrastructure is only used for the float tests, so we could move this infra into library/coretests/tests/floats, could we not?

Yeah long-term that's the right plan IMO.

As a thought, what if coretests/tests/floats/mod.rs (or coretests/tests/num.rs, whatever) defined macros that expand to test cases, rather than entire tests? So each float type defines its own test functions that can include type-specific tests, but some of the copy+paste and other redundancy is gone.

That seems like it'd make it harder to ensure we truly do have all the same tests for all float types though. I don't think we want to have f16.rs and f32.rs and so on on the test side.

Separately, it seems like it would be useful to have a #[test_const] proc macro that duplicates the test and wraps it in a const block with redefined assert* macros. Since there are a growing number of cases where we want to be able to verify behavior both at CTFE and at runtime.

I think something reasonably close can even be done as a regular macro.

@ruancomelli For this PR, maybe leave a FIXME comment both at the new and the old tests that this needs deduplicating? It'd also be worth opening an issue to track this and reference it from the FIXME.

Or, if the new tests do cover everything the existing test_floor have, remove the old ones, and file an issue for figuring out the organization here.

RalfJung · 2025-05-26T07:50:12Z

r? @RalfJung

…te with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`

…with a single, parametrized one

… `f16` and `f128`

compiler/rustc_const_eval/src/interpret/intrinsics.rs

rustbot assigned ibraheemdev May 24, 2025

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

ruancomelli force-pushed the const-float-rounding branch from bed4525 to 372e4cd Compare May 24, 2025 21:49

This comment has been minimized.

Sign in to view

CAD97 reviewed May 25, 2025

View reviewed changes

library/core/src/intrinsics/mod.rs Outdated Show resolved Hide resolved

library/core/src/num/f32.rs Outdated Show resolved Hide resolved

library/std/src/f64.rs Outdated Show resolved Hide resolved

RalfJung reviewed May 25, 2025

View reviewed changes

library/coretests/tests/num/mod.rs Show resolved Hide resolved

RalfJung reviewed May 25, 2025

View reviewed changes

tests/ui/consts/const-eval/float_methods.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

ruancomelli mentioned this pull request May 25, 2025

Tracking Issue for #![feature(const_float_round_methods)] #141555

Open

5 tasks

This comment has been minimized.

Sign in to view

RalfJung reviewed May 25, 2025

View reviewed changes

library/coretests/tests/num/mod.rs Show resolved Hide resolved

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 25, 2025

RalfJung mentioned this pull request May 26, 2025

Tracking Issue for const_float_euclidean_division #141572

Open

3 tasks

RalfJung reviewed May 26, 2025

View reviewed changes

RalfJung mentioned this pull request May 26, 2025

coretests: extend and simplify float tests #141571

Open

rustbot assigned RalfJung and unassigned ibraheemdev May 26, 2025

ruancomelli added 12 commits May 27, 2025 19:53

test: add tests that we expect to pass when float rounding becomes const

56ce2f3

feat: make float rounding methods const

8de1103

fix: replace rustc_allow_const_fn_unstable(core_intrinsics) attribu…

0b1d30e

…te with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`

revert: undo update to library/stdarch

ca8a8db

refactor: replace multiple float_<mode>_intrinsic rounding methods …

1113a19

…with a single, parametrized one

revert: undo changes to rint functions

d1bb3f0

fix: add #[cfg(not(bootstrap))] to new const method tests

b7fb0df

test: add extra sign tests to check +0.0 and -0.0

0e24d5c

revert: undo accidental changes to round docs

52ce976

fix: gate const float round method behind const_float_round_methods

b186fd1

fix: remove unnecessary #![feature(const_float_methods)]

0caa691

fix: remove unnecessary #![feature(const_float_methods)] [2]

74e3628

ruancomelli force-pushed the const-float-rounding branch from 4512002 to 74e3628 Compare May 27, 2025 23:23

revert: undo changes to tests/ui/consts/const-eval/float_methods.rs

3af13ac

This comment has been minimized.

Sign in to view

ruancomelli added 4 commits May 27, 2025 20:39

fix: adjust after rebase

e257f2f

test: fix float tests

ca73cae

test: add tests for fract

f8930f4

chore: add commented-out const_float_round_methods feature gates to…

c24e404

… `f16` and `f128`

This comment has been minimized.

Sign in to view

RalfJung reviewed May 28, 2025

View reviewed changes

compiler/rustc_const_eval/src/interpret/intrinsics.rs Show resolved Hide resolved

fix: adjust NaN when rounding floats

85056fd

feat: add const support for float rounding methods #141521

Are you sure you want to change the base?

feat: add const support for float rounding methods #141521

Conversation

ruancomelli commented May 24, 2025

Add const support for float rounding methods

Procedure

Question regarding the "unstability" attributes

Alternative implementation

Note

Uh oh!

rustbot commented May 24, 2025

Uh oh!

rustbot commented May 24, 2025

Uh oh!

RalfJung commented May 24, 2025

Uh oh!

RalfJung commented May 24, 2025

Uh oh!

This comment has been minimized.

ruancomelli commented May 24, 2025

Uh oh!

ruancomelli commented May 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

CAD97 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RalfJung commented May 25, 2025

Uh oh!

Uh oh!

Uh oh!

RalfJung commented May 25, 2025 via email

Uh oh!

This comment has been minimized.

ruancomelli commented May 25, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Uh oh!

RalfJung commented May 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented May 25, 2025

Uh oh!

rustbot commented May 25, 2025

Uh oh!

RalfJung May 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung May 26, 2025

Choose a reason for hiding this comment

Uh oh!

ruancomelli May 28, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 May 28, 2025

Choose a reason for hiding this comment

Uh oh!

tgross35 May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung May 28, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung commented May 26, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

feat: add `const` support for float rounding methods #141521

feat: add `const` support for float rounding methods #141521

Add `const` support for float rounding methods

ruancomelli commented May 25, 2025 •

edited

Loading

RalfJung commented May 25, 2025 •

edited

Loading

RalfJung May 26, 2025 •

edited

Loading

tgross35 May 28, 2025 •

edited

Loading

RalfJung May 28, 2025 •

edited

Loading