rust/library/alloc/tests
bors aef11409b4 Auto merge of #78618 - workingjubilee:ieee754-fmt, r=m-ou-se
Add IEEE 754 compliant fmt/parse of -0, infinity, NaN

This pull request improves the Rust float formatting/parsing libraries to comply with IEEE 754's formatting expectations around certain special values, namely signed zero, the infinities, and NaN. It also adds IEEE 754 compliance tests that, while less stringent in certain places than many of the existing flt2dec/dec2flt capability tests, are intended to serve as the beginning of a roadmap to future compliance with the standard. Some relevant documentation is also adjusted with clarifying remarks.

This PR follows from discussion in https://github.com/rust-lang/rfcs/issues/1074, and closes #24623.

The most controversial change here is likely to be that -0 is now printed as -0. Allow me to explain: While there appears to be community support for an opt-in toggle of printing floats as if they exist in the naively expected domain of numbers, i.e. not the extended reals (where floats live), IEEE 754-2019 is clear that a float converted to a string should be capable of being transformed into the original floating point bit-pattern when it satisfies certain conditions (namely, when it is an actual numeric value i.e. not a NaN and the original and destination float width are the same). -0 is given special attention here as a value that should have its sign preserved. In addition, the vast majority of other programming languages not only output `-0` but output `-0.0` here.

While IEEE 754 offers a broad leeway in how to handle producing what it calls a "decimal character sequence", it is clear that the operations a language provides should be capable of round tripping, and it is confusing to advertise the f32 and f64 types as binary32 and binary64 yet have the most basic way of producing a string and then reading it back into a floating point number be non-conformant with the standard. Further, existing documentation suggested that e.g. -0 would be printed with -0 regardless of the presence of the `+` fmt character, but it prints "+0" instead if given such (which was what led to the opening of #24623).

There are other parsing and formatting issues for floating point numbers which prevent Rust from complying with the standard, as well as other well-documented challenges on the arithmetic level, but I hope that this can be the beginning of motion towards solving those challenges.
2021-03-27 10:40:16 +00:00
..
arc.rs mv std libs to library/ 2020-07-27 19:51:13 -05:00
binary_heap.rs in-place collect for Vec. Box<[]> and BinaryHeap IntoIter and some adapters 2020-09-03 20:59:03 +02:00
borrow.rs Move various ui const tests to library 2020-09-04 02:35:27 +02:00
boxed.rs review: fix nits and move panic safety tests to the correct place 2020-09-25 23:10:24 +02:00
btree_set_hash.rs Move btree unit test to their native, privileged location 2020-08-14 17:54:09 +02:00
cow_str.rs mv std libs to library/ 2020-07-27 19:51:13 -05:00
fmt.rs Auto merge of #78618 - workingjubilee:ieee754-fmt, r=m-ou-se 2021-03-27 10:40:16 +00:00
heap.rs Rename AllocRef to Allocator and (de)alloc to (de)allocate 2020-12-04 14:47:15 +01:00
lib.rs Revert "Revert stabilizing integer::BITS." 2021-03-24 22:34:36 +01:00
linked_list.rs mv std libs to library/ 2020-07-27 19:51:13 -05:00
rc.rs mv std libs to library/ 2020-07-27 19:51:13 -05:00
slice.rs Update the bootstrap compiler 2021-02-20 17:19:30 -05:00
str.rs break formatting so rustfmt is happy 2020-12-02 14:09:36 +01:00
string.rs Implement String::remove_matches 2021-03-05 11:27:58 -05:00
vec_deque.rs replace assert! with assert_eq! 2020-12-13 10:21:24 +01:00
vec.rs Vec::dedup optimization - add benches 2021-03-16 14:41:26 +01:00