Rollup merge of #139483 - RalfJung:nan, r=tgross35
f*::NAN: guarantee that this is a quiet NaN I think we should guarantee that this is a quiet NaN. This then implies that programs not using `f*::from_bits` (or unsafe type conversions) are guaranteed to only work with quiet NaNs. It would be awkward if people start to write `0.0 / 0.0` instead of using the constant just because they want to get a guaranteed-quiet NaN. This is a `@rust-lang/libs-api` change. The definition of this constant currently is `0.0 / 0.0`, which is already guaranteed to be a quiet NaN. So all this does is forward that guarantee to our users.
This commit is contained in:
commit
b6e48d3850
5 changed files with 41 additions and 33 deletions
|
@ -224,14 +224,16 @@ impl f128 {
|
|||
|
||||
/// Not a Number (NaN).
|
||||
///
|
||||
/// Note that IEEE 754 doesn't define just a single NaN value;
|
||||
/// a plethora of bit patterns are considered to be NaN.
|
||||
/// Furthermore, the standard makes a difference
|
||||
/// between a "signaling" and a "quiet" NaN,
|
||||
/// and allows inspecting its "payload" (the unspecified bits in the bit pattern).
|
||||
/// This constant isn't guaranteed to equal to any specific NaN bitpattern,
|
||||
/// and the stability of its representation over Rust versions
|
||||
/// and target platforms isn't guaranteed.
|
||||
/// Note that IEEE 754 doesn't define just a single NaN value; a plethora of bit patterns are
|
||||
/// considered to be NaN. Furthermore, the standard makes a difference between a "signaling" and
|
||||
/// a "quiet" NaN, and allows inspecting its "payload" (the unspecified bits in the bit pattern)
|
||||
/// and its sign. See the [specification of NaN bit patterns](f32#nan-bit-patterns) for more
|
||||
/// info.
|
||||
///
|
||||
/// This constant is guaranteed to be a quiet NaN (on targets that follow the Rust assumptions
|
||||
/// that the quiet/signaling bit being set to 1 indicates a quiet NaN). Beyond that, nothing is
|
||||
/// guaranteed about the specific bit pattern chosen here: both payload and sign are arbitrary.
|
||||
/// The concrete bit pattern may change across Rust versions and target platforms.
|
||||
#[allow(clippy::eq_op)]
|
||||
#[rustc_diagnostic_item = "f128_nan"]
|
||||
#[unstable(feature = "f128", issue = "116909")]
|
||||
|
|
|
@ -219,14 +219,16 @@ impl f16 {
|
|||
|
||||
/// Not a Number (NaN).
|
||||
///
|
||||
/// Note that IEEE 754 doesn't define just a single NaN value;
|
||||
/// a plethora of bit patterns are considered to be NaN.
|
||||
/// Furthermore, the standard makes a difference
|
||||
/// between a "signaling" and a "quiet" NaN,
|
||||
/// and allows inspecting its "payload" (the unspecified bits in the bit pattern).
|
||||
/// This constant isn't guaranteed to equal to any specific NaN bitpattern,
|
||||
/// and the stability of its representation over Rust versions
|
||||
/// and target platforms isn't guaranteed.
|
||||
/// Note that IEEE 754 doesn't define just a single NaN value; a plethora of bit patterns are
|
||||
/// considered to be NaN. Furthermore, the standard makes a difference between a "signaling" and
|
||||
/// a "quiet" NaN, and allows inspecting its "payload" (the unspecified bits in the bit pattern)
|
||||
/// and its sign. See the [specification of NaN bit patterns](f32#nan-bit-patterns) for more
|
||||
/// info.
|
||||
///
|
||||
/// This constant is guaranteed to be a quiet NaN (on targets that follow the Rust assumptions
|
||||
/// that the quiet/signaling bit being set to 1 indicates a quiet NaN). Beyond that, nothing is
|
||||
/// guaranteed about the specific bit pattern chosen here: both payload and sign are arbitrary.
|
||||
/// The concrete bit pattern may change across Rust versions and target platforms.
|
||||
#[allow(clippy::eq_op)]
|
||||
#[rustc_diagnostic_item = "f16_nan"]
|
||||
#[unstable(feature = "f16", issue = "116909")]
|
||||
|
|
|
@ -470,14 +470,16 @@ impl f32 {
|
|||
|
||||
/// Not a Number (NaN).
|
||||
///
|
||||
/// Note that IEEE 754 doesn't define just a single NaN value;
|
||||
/// a plethora of bit patterns are considered to be NaN.
|
||||
/// Furthermore, the standard makes a difference
|
||||
/// between a "signaling" and a "quiet" NaN,
|
||||
/// and allows inspecting its "payload" (the unspecified bits in the bit pattern).
|
||||
/// This constant isn't guaranteed to equal to any specific NaN bitpattern,
|
||||
/// and the stability of its representation over Rust versions
|
||||
/// and target platforms isn't guaranteed.
|
||||
/// Note that IEEE 754 doesn't define just a single NaN value; a plethora of bit patterns are
|
||||
/// considered to be NaN. Furthermore, the standard makes a difference between a "signaling" and
|
||||
/// a "quiet" NaN, and allows inspecting its "payload" (the unspecified bits in the bit pattern)
|
||||
/// and its sign. See the [specification of NaN bit patterns](f32#nan-bit-patterns) for more
|
||||
/// info.
|
||||
///
|
||||
/// This constant is guaranteed to be a quiet NaN (on targets that follow the Rust assumptions
|
||||
/// that the quiet/signaling bit being set to 1 indicates a quiet NaN). Beyond that, nothing is
|
||||
/// guaranteed about the specific bit pattern chosen here: both payload and sign are arbitrary.
|
||||
/// The concrete bit pattern may change across Rust versions and target platforms.
|
||||
#[stable(feature = "assoc_int_consts", since = "1.43.0")]
|
||||
#[rustc_diagnostic_item = "f32_nan"]
|
||||
#[allow(clippy::eq_op)]
|
||||
|
|
|
@ -469,14 +469,16 @@ impl f64 {
|
|||
|
||||
/// Not a Number (NaN).
|
||||
///
|
||||
/// Note that IEEE 754 doesn't define just a single NaN value;
|
||||
/// a plethora of bit patterns are considered to be NaN.
|
||||
/// Furthermore, the standard makes a difference
|
||||
/// between a "signaling" and a "quiet" NaN,
|
||||
/// and allows inspecting its "payload" (the unspecified bits in the bit pattern).
|
||||
/// This constant isn't guaranteed to equal to any specific NaN bitpattern,
|
||||
/// and the stability of its representation over Rust versions
|
||||
/// and target platforms isn't guaranteed.
|
||||
/// Note that IEEE 754 doesn't define just a single NaN value; a plethora of bit patterns are
|
||||
/// considered to be NaN. Furthermore, the standard makes a difference between a "signaling" and
|
||||
/// a "quiet" NaN, and allows inspecting its "payload" (the unspecified bits in the bit pattern)
|
||||
/// and its sign. See the [specification of NaN bit patterns](f32#nan-bit-patterns) for more
|
||||
/// info.
|
||||
///
|
||||
/// This constant is guaranteed to be a quiet NaN (on targets that follow the Rust assumptions
|
||||
/// that the quiet/signaling bit being set to 1 indicates a quiet NaN). Beyond that, nothing is
|
||||
/// guaranteed about the specific bit pattern chosen here: both payload and sign are arbitrary.
|
||||
/// The concrete bit pattern may change across Rust versions and target platforms.
|
||||
#[rustc_diagnostic_item = "f64_nan"]
|
||||
#[stable(feature = "assoc_int_consts", since = "1.43.0")]
|
||||
#[allow(clippy::eq_op)]
|
||||
|
|
|
@ -13,7 +13,7 @@ pub fn main() {
|
|||
TLS.set(Some(Box::leak(Box::new(123))));
|
||||
|
||||
// We can only ignore leaks on targets that use `#[thread_local]` statics to implement
|
||||
// `thread_local!`. Ignore the test on targest that don't.
|
||||
// `thread_local!`. Ignore the test on targets that don't.
|
||||
if cfg!(target_thread_local) {
|
||||
thread_local! {
|
||||
static TLS_KEY: Cell<Option<&'static i32>> = Cell::new(None);
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue