Tracking Issue for `float_semantics` RFC 3514

This is a tracking issue for RFC 3514:

https://github.com/rust-lang/rfcs/pull/3514

The feature gate for the issue is #![feature(float_semantics)].

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

[x] Accept an RFC.
- https://github.com/rust-lang/rfcs/pull/3514
[ ] Update library documentation.
- https://github.com/rust-lang/rust/pull/129559
[ ] Add documentation to the reference.
- See the instructions.
N/A: Add formatting for new syntax to the style guide.
- See the nightly style procedure.
[ ] Stabilize.
- https://github.com/rust-lang/rust/pull/128596

Unresolved Questions

[ ] Should we be concerned that LLVM does not actually document that it uses IEEE float semantics? It does assume IEEE semantics in its own optimization passes.
[ ] Are there any other targets with floating-point trouble?
[ ] What exactly is the set of "extra" NaNs for all remaining targets?
[ ] To what extend does this specification apply to platform intrinsics? On the one hand, it seems reasonable to expect platform intrinsics to have the behavior of the platform instructions. On the other hand, we implement some platform intrinsics with the portable LLVM simd intrinsics, and those are subject to the NaN-non-determinism described above. So the current de-facto semantics of at least some platform intrinsics is that they do not match what the platform does.

TODO.

cc @RalfJung @rust-lang/lang

rust-lang / rust