Make some float methods unstable const fn

[eduardosm]

Some float methods are now const fn under the const_float_methods feature gate.

I also made some unstable methods const fn, keeping their constness under their respective feature gate.

In order to support min, max, abs and copysign, the implementation of some intrinsics had to be moved from Miri to rustc_const_eval (cc @RalfJung).

Tracking issue: #130843

impl <float> {
    // #[feature(const_float_methods)]
    pub const fn recip(self) -> Self;
    pub const fn to_degrees(self) -> Self;
    pub const fn to_radians(self) -> Self;
    pub const fn max(self, other: Self) -> Self;
    pub const fn min(self, other: Self) -> Self;
    pub const fn clamp(self, min: Self, max: Self) -> Self;
    pub const fn abs(self) -> Self;
    pub const fn signum(self) -> Self;
    pub const fn copysign(self, sign: Self) -> Self;

    // #[feature(float_minimum_maximum)]
    pub const fn maximum(self, other: Self) -> Self;
    pub const fn minimum(self, other: Self) -> Self;

    // Only f16/f128 (f32/f64 already const)
    pub const fn is_sign_positive(self) -> bool;
    pub const fn is_sign_negative(self) -> bool;
    pub const fn next_up(self) -> Self;
    pub const fn next_down(self) -> Self;
}

r? libs-api

try-job: dist-s390x-linux

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

[RalfJung]

r=me on the interpreter and Miri parts.

[eduardosm]

I made clamp const too, using an approach similar to #130611 to handle the assert formatting.

[tgross35]

If this is accepted, a tracking issue should be created (for now I set issue = "none").

You can go ahead and do this in advance, I don't think there is any reason these would be rejected

[eduardosm]

Created tracking issue: #130843

For f16/f32 methods, I placed commented gates under the same feature as f32/f64 (e.g., is_sign_positive under const_float_classify, next_up under float_next_up_down).

[bors]

☔ The latest upstream changes (presumably #130157) made this pull request unmergeable. Please resolve the merge conflicts.

I believe is_sign_positive / is_sign_negative do not need the second unstable gate since const_float_classify is now stable.

Suggested change

	enum FloatBinOp {
	enum FloatBinIntrinsic {

We use BinOp for the MIR binops, IMO we shouldn't mix up that terminology.

Also please move this above the functions that use it.

LGTM from the interpreter side.

r? libs-api

Rebased to pick #131256 and remove #![feature(f16_const)] and #![feature(f128_const)].

☔ The latest upstream changes (presumably #131581) made this pull request unmergeable. Please resolve the merge conflicts.

If libs-api can just okay unstably adding const to the signatures, I'm happy to review the rest.

@rustbot label +I-libs-api-nominated

The unstable const APIs LGTM (on the basis that we're doing the same for f32 and f64).

@bors rollup=never

Ah yeah yuck, every function in stdlib that takes a f16 or f128 in the signature still needs #[inline] so LLVM doesn't try to codegen and crash on platforms where that is buggy. This includes the assert_at_const and assert_at_rt functions.

Fixed by adding #[inline] to assert_at_const. Tested locally with ./x build --target s390x-unknown-linux-gnu library/core

@bors r=RalfJung,tgross35 rollup

📌 Commit c09ed3e has been approved by RalfJung,tgross35

It is now in the queue for this repository.

Ah yeah yuck, every function in stdlib that takes a f16 or f128 in the signature still needs #[inline] so LLVM doesn't try to codegen and crash on platforms where that is buggy. This includes the assert_at_const and assert_at_rt functions.

Wow f16 / f128 are more unstable than I thought.^^ Is there an issue tracking specifically the codegen crashes? Can we have a central workaround instead of dozens of #[inline] everywhere where we will surely forget to remove some?

Wow f16 / f128 are more unstable than I thought.^^ Is there an issue tracking specifically the codegen crashes? Can we have a central workaround instead of dozens of #[inline] everywhere where we will surely forget to remove some?

The list of platforms where just seeing the types is enough to make LLVM crash is fortunately pretty limited, wasm and arm64ec being some notably more popular exceptions https://github.com/rust-lang/compiler-builtins/blob/cb060052ab7e4bad408c85d44be7e60096e93e38/configure.rs#L53-L77. AIUI however, we need the inline annotations anyway since Cranelift doesn't support the types, and having anything not inline would mean it can't compile std.

I'm not sure what would be better here.

I'm not sure what would be better here.

We can automatically mark functions as inline if they have a f16/f128 argument. 🙈

That works 😄

The codegen crashes are currently tracked as part of the big list in the tracking issue at #116909 (comment), but there isn't a separate dedicated tracking issue just for them. Adding a cfg via core/std's build.rs for whether f16/f128 codegen will succeed or not is definitely possible: compiler-builtins already has such a cfg, and std already has a different list for whether f16/f128 tests will pass or not.

Specifically, the logic here, which already makes "small" functions auto-#[inline], could also check the signature.