Possible float parsing bug

[MasonRemaley]

Zig Version

0.14.0-dev.23+d9bd34fd0

Steps to Reproduce and Observed Behavior

The following test fails:

test "float issue" {
    const a: f32 = 0xffffffffffffffff.0p0;
    const b: f32 = try std.fmt.parseFloat(f32, "0xffffffffffffffff.0p0");
    try std.testing.expectEqual(a, b); // failed: expected 1.8446744e19, found 1.1529215e18
}

At first glance it's hard to imagine why this would fail, since the compiler itself is using parseFloat as well. However, the compiler always parses floats as f128s, so here's a more illustrative test case:

test "float issue" {
    const a: f32 = try std.fmt.parseFloat(f32, "0xffffffffffffffff.0p0");
    const b: f32 = @floatCast(try std.fmt.parseFloat(f128, "0xffffffffffffffff.0p0"));
    try std.testing.expectEqual(a, b); // failed: expected 1.1529215e18, found 1.8446744e19
}

If I understand the situation correctly, this should pass:

• Parsing as a f32 should get the closest possible f32 representation to the given number
• Parsing as a f128 should get the closest possible f128 to the given number, and then float casting that should round to the closest possible f32 to that number
• These results should therefore be the same, but they are not for the example value and other very large values

Besides resulting in an incorrect value, this has a minor detrimental effect on #20271--in the interest of being consistent results with Zig, the ZON parser has to parse all floats as f128s even when it knows the destination precision and could technically save time by parsing as f32s.

I suspect that the cause of this is related to either rounding modes or handling of very large/out of range floats, but I'm not sure how to dig in further.

Expected Behavior

I expected parsing floating point literal strings as a given type to produce the same result as including that literal in the source code and ascribing the same type.