No "weird" floats in const fn {from,to}_bits

[workingjubilee]

I suspect this code is subtly incorrect and that we don't even e.g. use x87-style floats in CTFE, so I don't have to guard against that case. A future PR will be hopefully removing them from concern entirely, anyways. But at the moment I wanted to get this rolling because small questions like that one seem best answered by review.

r? @oli-obk
cc @eddyb @thomcc

[rust-highfive]

Thank you for submitting a new PR for the library teams! If this PR contains a stabilization of a library feature that has not already completed FCP in its tracking issue, introduces new or changes existing unstable library APIs, or changes our public documentation in ways that create new stability guarantees then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary

[oli-obk]

oof. What you write makes sense, but I have no way of verifying it beyond looking at the CTFE logic and agreeing that it makes sense.

we don't even e.g. use x87-style floats in CTFE, so I don't have to guard against that case.

yea, we don't. Our impl is "perfectly IEEE compliant". I am fully aware how useless that fact is, considering hardware and LLVM do what they do.

[workingjubilee]

oof. What you write makes sense, but I have no way of verifying it beyond looking at the CTFE logic and agreeing that it makes sense.

we don't even e.g. use x87-style floats in CTFE, so I don't have to guard against that case.

yea, we don't. Our impl is "perfectly IEEE compliant". I am fully aware how useless that fact is, considering hardware and LLVM do what they do.

That's fine! It's my job to bring those two more into alignment, one way or another. 😈

[workingjubilee]

Fixed up comments and removed unnecessary x87-specific logic for const time.

[oli-obk]

This gets us closer to floats in const fn. I'll address the use of const_eval_select after this is merged.

@bors r+

[bors]

📌 Commit 4da8682 has been approved by oli-obk

[bors]

⌛ Testing commit 4da8682 with merge cacaef022ae549251cf088cf0e2cf93abb505675...

[bors]

💔 Test failed - checks-actions

[rust-log-analyzer]

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

.......... (60/62)
.         (62/62)


/checkout/src/test/rustdoc-gui/search-tab-selection-if-current-is-empty.goml search-tab-selection-if-current-is-empty... FAILED
[ERROR] (line 6) TimeoutError: waiting for selector "#titles" failed: timeout 30000ms exceeded: for command `wait-for: "#titles"`
Build completed unsuccessfully in 0:00:45

[oli-obk]

@bors retry TimeoutError: waiting for selector "#titles" failed: timeout 30000ms

[bors]

⌛ Testing commit 4da8682 with merge 1e9aa8a...

[bors]

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 1e9aa8a to master...

[rust-timer]

Finished benchmarking commit (1e9aa8a): comparison url.

Summary: This benchmark run did not return any relevant results.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

[RalfJung]

Should the doc comments of these functions explicitly mention their restrictions when used in const context?

[workingjubilee]

Probably would be best if they did, yes.