Fix handling of NaN sign throughout parsing and serialization

[dtolnay]

I learned recently in rust-lang/miri#3139 that as produces NaN with a nondeterministic sign, and separately that the sign of f64::NAN is not specified (may be a negative NaN). As of rust-lang/rust#116551 Miri has begun intentionally exercising these cases.

This PR fixes places where -nan would incorrectly be deserialized as a positive NaN, nan or +nan would be deserialized as a negative NaN, negative NaN would be serialized as nan, or positive NaN would be serialized as -nan. It adds tests to confirm the expected sign of NaN values, and improves existing tests related to NaN.

[dtolnay]

Pre-commit failure appears unrelated: #638.

[epage]

Wow, that is terrible. Thanks for not just letting me know, but fixing ! I've at least opened rust-lang/rust-clippy#11717 and rust-lang/rust-clippy#11718 in the hopes that we can enforce catching of these problems in the future.

[epage]

To double check my understanding, we should also have a copysign on this use of nan, right?

https://github.com/toml-rs/toml/blob/main/crates/toml_edit/src/parser/numbers.rs#L304

EDIT: I'm fine merging as-is and fixing it myself if you want as some improvement is better than no improvement; I just want to make sure I understand.

[dtolnay]

Indeed; good call.

[epage]

Thanks! This last change made me realize I need to go request another pedantic clippy lint: nan constants without a sign.

[RalfJung]

Note that there are other bits in the NaN (observable via to_bits()) that are still potentially lost in the conversion.

I am somewhat surprised that the sign of the NaN is considered so significant that there were a bunch of tests checking it, and that the code is being adjusted to preserve it. What is the motivation for that? rust-lang/rfcs#3514 should possibly be amended to at least document this as a downside of the non-deterministic sign semantics.

[epage]

I am somewhat surprised that the sign of the NaN is considered so significant that there were a bunch of tests checking it, and that the code is being adjusted to preserve it. What is the motivation for that

The sign of nan is specified in the TOML spec, so to be able to properly preserve it, we need to track it.