coretests: move float tests from num to floats module and use a more flexible macro to generate them
This makes some progress on https://github.com/rust-lang/rust/issues/141726 by moving the float tests in `num` to `floats` and using a newer, more flexible macro to generate them. We also newly run these tests on f16 and f128 in const, and at runtime in Miri and for hosts where that works well enough.
I didn't yet deduplicate any tests or port the existing `floats::f*` tests to the macro, that can happen in a future PR.
try-job: x86_64-gnu-aux
Some history: The Zip TrustedRandomAccess specialization has tried
to emulate the side-effects of the naive implementation for a long time,
including backwards iteration. 82292¹ tried to fix unsoundness (82291¹) in that
side-effect-preservation code, but this introduced some panic-safety
unsoundness (86443¹), but the fix 86452¹ didn't fix it for nested Zip
iterators (137255¹).
Rather than piling yet another fix ontop of this heap of fixes this PR reduces
the number of cases in which side-effects will be preserved; the necessary
API guarantee change was approved in 83791¹ but we haven't made use of that
so far.
¹ see merge commit for linkfied issues.
exact_div: add tests
tracking issue: rust-lang/rust#139911
I neglected to add tests in my last PR (rust-lang/rust#141237), so I've added them here.
r? ``@workingjubilee`` (Feel free to reroll, I just picked you since you reviewed the last one.)
Add const support for the float rounding methods floor, ceil, trunc,
fract, round and round_ties_even.
This works by moving the calculation logic from
src/tools/miri/src/intrinsics/mod.rs
into
compiler/rustc_const_eval/src/interpret/intrinsics.rs.
All relevant method definitions were adjusted to include the `const`
keyword for all supported float types: f16, f32, f64 and f128.
The constness is hidden behind the feature gate
feature(const_float_round_methods)
which is tracked in
https://github.com/rust-lang/rust/issues/141555
This commit is a squash of the following commits:
- test: add tests that we expect to pass when float rounding becomes const
- feat: make float rounding methods `const`
- fix: replace `rustc_allow_const_fn_unstable(core_intrinsics)` attribute with `#[rustc_const_unstable(feature = "f128", issue = "116909")]` in `library/core/src/num/f128.rs`
- revert: undo update to `library/stdarch`
- refactor: replace multiple `float_<mode>_intrinsic` rounding methods with a single, parametrized one
- fix: add `#[cfg(not(bootstrap))]` to new const method tests
- test: add extra sign tests to check `+0.0` and `-0.0`
- revert: undo accidental changes to `round` docs
- fix: gate `const` float round method behind `const_float_round_methods`
- fix: remove unnecessary `#![feature(const_float_methods)]`
- fix: remove unnecessary `#![feature(const_float_methods)]` [2]
- revert: undo changes to `tests/ui/consts/const-eval/float_methods.rs`
- fix: adjust after rebase
- test: fix float tests
- test: add tests for `fract`
- chore: add commented-out `const_float_round_methods` feature gates to `f16` and `f128`
- fix: adjust NaN when rounding floats
- chore: add FIXME comment for de-duplicating float tests
- test: remove unnecessary test file `tests/ui/consts/const-eval/float_methods.rs`
- test: fix tests after upstream simplification of how float tests are run
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]: https://github.com/rust-lang/rust/pull/138087#issuecomment-2842069281
The first commit is a small bit of macro cleanup.
try-job: aarch64-gnu
try-job: x86_64-gnu-aux
`assert_eq!` ignores the sign of zero, but for any tests involving zeros
we do care about this sign. Replace `assert_eq!` with `assert_biteq!`
everywhere possible for float tests to ensure we don't miss this.
`assert_biteq!` is also updated to check equality on non-NaNs, to catch
the unlikely case that bitwise equality works but our `==`
implementation is broken.
There is one notable output change: we were asserting that
`(-0.0).fract()` and `(-1.0).fract()` both return -0.0, but both
actually return +0.0.
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]: https://github.com/rust-lang/rust/pull/138087#issuecomment-2842069281
float: Disable `total_cmp` sNaN tests for `f16`
There is an LLVM bug with lowering of basic `f16` operations that mean a round trip via `__extendhfsf2` and `__truncsfhf2` may happen for simple `abs` calls or bitcasts [1]. This is problematic because the round trip quiets signaling NaNs. For most operations this is acceptable, but it is causing `total_cmp` tests to fail unless optimizations are enabled.
Disable `total_cmp` tests involving signaling NaNs until this issue is resolved.
Fixes: https://github.com/rust-lang/rustc_codegen_cranelift/issues/1578
Fixes: https://github.com/rust-lang/rust/issues/141503
[1]: https://github.com/llvm/llvm-project/issues/104915
When these functions were added in
https://github.com/rust-lang/rust/pull/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.
Extend the existing tests for `f32` and `f64` with versions that include
`f16`'s new printing and parsing implementations.
Co-authored-by: Speedy_Lex <alex.ciocildau@gmail.com>
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: https://github.com/rust-lang/rust/issues/137578
[1]: https://github.com/rust-lang/compiler-builtins/pull/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
Add `#[must_use]` to Array::map
The output of Array::map is intended to be an array of the same size, and does not modify the original in place nor is it intended for side-effects. Thus, under normal circumstances it should be consumed.
See [discussion](https://internals.rust-lang.org/t/array-map-annotate-with-must-use/22813/26).
Attaching to tracking issue #75243
The previous commit moved all test files from `std` to `core` so git
understands the move. Not all functionality is actually testable in
`core`, however, so perform move the relevant portions back. Changes
from inherent to module methods is also done since this is the form of
math operations available in `core` (as `core_float_math`).
Many float-related tests in `std` only depend on `core`, so move the
tests there. This also allows us to verify functions from
`core_float_math`.
Since the majority of test files need to be moved to `coretests`, move
the files here without any cleanup; this is done in a followup commit.
This makes git history slightly cleaner, but coretests will not build
immediately after this commit.
The output of Array::map is intended to be an array of the same size, and does not modify the
original in place nor is it intended for side-effects. Thus, under normal circumstances it should be consumed.
See [discussion](https://internals.rust-lang.org/t/array-map-annotate-with-must-use/22813/26).
Attaching to tracking issue #75243
stabilize ptr::swap_nonoverlapping in const
Closes https://github.com/rust-lang/rust/issues/133668
The blocking issue mentioned there is resolved by documentation. We may in the future actually support such code, but that is blocked on https://github.com/rust-lang/const-eval/issues/72 which is non-trivial to implement. Meanwhile, this completes stabilization of all `const fn` in `ptr`. :)
Here's a version of the problematic example to play around with:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6c390452379fb593e109b8f8ee854d2a
Should be FCP'd with both `@rust-lang/libs-api` and `@rust-lang/lang` since `swap_nonoverlapping` is documented to work as an "untyped" operation but due to the limitation mentioned above, that's not entirely true during const evaluation. I expect this limitation will only be hit in niche corner cases, so the benefits of having this function work most of the time outweigh the downsides of users running into this problem. (Note that unsafe code could already hit this limitation before this PR by doing cursed pointer casts, but having it hidden inside `swap_nonoverlapping` feels a bit different.)
add next_index to Enumerate
Proposal: https://github.com/rust-lang/libs-team/issues/435
Tracking Issue: #130711
This basically just reopens#130682 but squashed and with the new function and the feature gate renamed to `next_index.`
There are two questions I have already:
- Shouldn't we add test coverage for that? I'm happy to provide some, but I might need a pointer to where these test would be.
- Maybe I could actually also add a doctest?
- For now, I just renamed the feature name in the unstable attribute to `next_index`, as well, so it matches the new name of the function. Is that okay? And can I just do that and use any string, or is there a sealed list of features defined somewhere where I also need to change the name?
