Unify and deduplicate float tests

[RalfJung]

We currently have at least two somewhat independent places where float functions are being tested:

• in coretests/tests/float/mod.rs
• in coretests/tests/floats/f*.rs
• in std/tests/floats/f*.rs

Confusingly, coretests also tests things that are actually in std. The ones in num have infrastructure to also run tests in const, but do not have infrastructure to e.g. only run f128 tests on targets where that is reliable. For this reason, some tests are duplicated.

We should make sure we have one canonical place for all these tests that can serve the needs of all of them, and avoid duplication.

Cc @tgross35

Mentoring instructions

The main goal is to port the tests that are still in coretests/tests/floats/f*.rs to use the infrastructure that we built in coretests/tests/float/mod.rs. So to help:

• pick a test or a set of related tests in coretests/tests/floats/f64.rs
• compare that with the versions in the other f*.rs files to see if they have anything beyond what f64 has
• add a new test in float/mod.rs that replaces the ones in f*.rs; see the existing tests there for examples

[RalfJung]

I prototyped a macro that would let us write tests like this:

#[test]
fn test_min() {
    float_test!(
        for Float in (
            #[cfg(target_has_reliable_f16_math)] f16,
            f32, f64,
            #[cfg(target_has_reliable_f128_math)] #[cfg(not(miri))] f128,
            const { f16, f32, f64, f128, },
        ) {
            float_assert!((0.0 as Float).min(0.0), 0.0);
        }
    );
}

See the playground for sources.

@tgross35 what do you think?

[bjorn3]

Maybe pull the float_test!() macro out of the test function? So in case of a test failure, you get separate test entries for the different float types. Could be useful to know if you broke floats as a whole or just f16 or f128 floats.

[RalfJung]

Hm yeah that should work:

float_test!(min:
    for Float in (
        #[cfg(target_has_reliable_f16_math)] f16,
        f32, f64,
        #[cfg(target_has_reliable_f128_math)] #[cfg(not(miri))] f128,
        const { f16, f32, f64, f128, },
    ) {
        float_assert!((0.0 as Float).min(0.0), 0.0);
    }
);

Output:

running 7 tests
test min::const_::f128 ... ok
test min::const_::f16 ... ok
test min::const_::f32 ... ok
test min::const_::f64 ... ok
test min::f16 ... ok
test min::f32 ... ok
test min::f64 ... ok

Full code

[tgross35]

Something like that seems reasonable enough to me. The config is a bit messy to read, but I don't have any better proposals.

Instead of float_assert!, could we create a module defining const-usable assert, assert_eq, assert_biteq, and assert_approx_eq macros, then bring those into scope for the const tests? Seems easier than going through a single float_assert!.

Also note that changes here may race with #141669, hopefully that one can get in first.

[RalfJung]

Instead of float_assert!, could we create a module defining const-usable assert, assert_eq, assert_biteq, and assert_approx_eq macros, then bring those into scope for the const tests? Seems easier than going through a single float_assert!.

Modules and macros interact in funny ways, but this variant seems to work.

I made it so that the entire test is put in a const block for the const versions. This has the advantage that if you use a macro that does not have a special const version, it'll still execute at const-time properly. It has the disadvantage that failing const tests fail when the test is being built, not when it is executed.

Also note that changes here may race with #141669, hopefully that one can get in first.

I intended to wait for some other stuff anyway before making an attempt here -- so I can just wait for that PR as well.

[RalfJung]

Turns out we have even more tests in library/std/tests/floats. Ideally we'd share the testing infrastructure

[tgross35]

As a possible alternative, I prototyped something that always emits tests for all float types so we don't accidentally forget any, but allows adding specific config.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=e03c7085c27cd29207d6ee40adda8e05

#[cfg(test)]
float_test! {
    name: min,
    attrs: {
        f16: [cfg(target_has_reliable_f16_math)],
        // no f64 tests for whatever reason
        f64: [cfg(false)],
        const f64: [cfg(false)],
        // Not implemented with miri
        f128: [cfg(target_has_reliable_f128_math), cfg(miri)],
        const f128: [cfg(target_has_reliable_f128_math), cfg(miri)],
    },
    tests: {
        assert!(!Float::NAN.min(0.0).is_nan(), "unexpected nan");
        assert_eq!((0.0 as Float).min(0.0), 0.0, "hi");
    },
}

Turns out we have even more tests in library/std/tests/floats. Ideally we'd share the testing infrastructure

Hopefully more of that will move to core in the future anyway :)

[RalfJung]

As a possible alternative, I prototyped something that always emits tests for all float types so we don't accidentally forget any, but allows adding specific config.

The way that works, if I use any other test macro those tests will not actually be run at const-time ever. (But that's orthogonal to always emitting all types vs iterating over the list of types.)

I figured iterating over the list would be needed to make this handle all cases, but I like your approach with cfg(false). IIUC it will default to just running the tests for all of them, and one has to opt-out rather than opt-in? That's neat.