[stdlib] Adjust floating-point nextUp test for NaN

[xwu]

In #15021, we used self + 0 to silence signaling NaN, as is appropriate.

In Swift, addition of zero does not preserve the sign of NaN (although it does preserve any payload). Rather, (-Double.nan + 0).sign == .plus. Since IEEE 754-2008 §6.2 permits implementations to make their own best effort at propagating NaN diagnostics, this behavior seems to be fine.

What it does mean, however, is testing for a specific bit pattern will fail when it comes to (-Double.nan).nextUp after we change our implementation. Therefore, let's change the test before we try to restore #15021.

[xwu]

@swift-ci Please test

[xwu]

/cc @stephentyrone

[stephentyrone]

self + 0 is actually formally the most correct result. IEEE 754 says that operations (except for the signbit operations) do not interpret the sign of NaN, so there's no expectation of what the signbit or payload should be per IEEE 754.

However, we should match the platform's behavior for NaN-propagation in arithmetic, which is precisely what self + 0 does. So there are two approaches here that would be defensible:

• For any NaN x, require that x.nextUp and x.nextDown are some quiet NaN.
• For any NaN x, require that x.nextUp and x.nextDown are bitwise identical to x + 0. (*)

If we choose the second option, the current implementation will fail, of course. So we should probably choose the first, and then tighten it later if we like.

(*) This is actually too strong of a condition, because IEEE 754 does not require that the same operation on the same inputs produce the same NaN encoding (a platform might, e.g. choose to encode a pointer to a tree representing a backtrace of NaN propagation through the program). It will be satisfied by every platform that Swift currently supports, but is not future proof. So we should probably choose the first option.

[xwu]

Agree. Absent objections, I'll adjust the test as shown and re-apply the previous PR.