feat: add const support for float rounding methods
#141521
Conversation
|
r? @ibraheemdev rustbot has assigned @ibraheemdev. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred to the CTFE machinery The Miri subtree was changed cc @rust-lang/miri Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr Some changes occurred to the CTFE / Miri interpreter cc @rust-lang/miri |
Yes, that's a lot better I think. :) |
|
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. |
…te with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`
ruancomelli
force-pushed
the
const-float-rounding
branch
from
bed4525 to
372e4cd
Compare
This comment has been minimized.
This comment has been minimized.
…with a single, parametrized one
|
Strange, CI is failing with intrinsic is not supported at compile-time for each one of the new methods. |
|
As far as I can see, the main difference between the newly |
There was a problem hiding this comment.
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.
The problem occurs when building the tests. So you don't need to do any |
There was a problem hiding this comment.
No need to add two complete sets of tests.
There was a problem hiding this comment.
Hey @RalfJung - do you mean I should revert the changes to this file?
There was a problem hiding this comment.
Yeah -- you're good on test coverage with the other tests. I should look into removing this file entirely and having library tests for it instead.
|
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.
|
This comment has been minimized.
This comment has been minimized.
|
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 The second question: I added This is similar to what was done in the reference PR, even though they changed library/core/src/lib.rs (notice |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
There was a problem hiding this comment.
Could you add tests for fract here?
Good question! The typical thing we do is to gate it behind the #[rustc_const_unstable(feature = "f16", issue = "116909")]
// #[rustc_const_unstable(feature = "const_float_round_methods", issue = "141555")]
pub const fn trunc(self) -> self { ... }
Yes, that's fine. |
|
@rustbot author |
rustbot
added
S-waiting-on-author
|
Reminder, once the PR becomes ready for a review, use |
| @@ -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() { | |||
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.^^
|
r? @RalfJung |
Add
constsupport for float rounding methodsThis PR makes the following float rounding methods
const:f64::{floor, ceil, trunc, round, round_ties_even}f16,f32andf128Procedure
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)]inlibrary/core/src/intrinsics/mod.rs#[rustc_const_unstable(feature = "f16", issue = "116909")]inlibrary/core/src/num/f16.rs#[rustc_const_unstable(feature = "f128", issue = "116909")]inlibrary/core/src/num/f128.rs#[rustc_const_unstable(feature = "const_float_methods", issue = "130843")]inlibrary/core/src/num/32.rsandlibrary/core/src/num/f64.rsPlease 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,roundandround_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::Roundparameter: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!