Convert floats with Eisel-Lemire when std::from_chars is unavailable

[nlohmann]

Part of the stack for the zero-copy view (#5295). This change speeds up json::parse on its own; the view uses it later.

Summary

Some float tokens are too long for Clinger's fast path, e.g. the 17-digit coordinates of canada.json. Such tokens go to strtod unless std::from_chars is available, and it is not:

• in C++11 and C++14;
• with libc++, which has the float overloads but does not define __cpp_lib_to_chars, so macOS builds never used it.

These tokens are now converted with the Eisel-Lemire algorithm, adapted from fast_float's compute_float. It uses integer arithmetic only.

• Up to 19 significant digits: the result is correctly rounded, and no fallback is needed (Mushtak and Lemire, 2023).
• Longer tokens: the mantissa is truncated to 19 digits. The result is used when the truncated value w and w + 1 round to the same double; otherwise strtod decides, as before.
• Overflow: still yields infinity, and with it out_of_range.406.

Changes

• detail/input/number_parse.hpp: eisel_lemire() and parse_float_eisel_lemire(), for double; float and long double take the existing path.
• detail/input/pow5_table.hpp: the 128-bit powers of five from fast_float, in a function-local static.
• detail/bit_ops.hpp: count_leading_zeros(), a 64×64→128-bit multiplication, and read_eight_bytes(). Each has a portable fallback where there is no builtin or __int128, and none depends on the byte order.
• README and license.md: credit for fast_float (MIT, Apache 2.0, or BSL; used under MIT).

Tests

New test case in unit-class_lexer.cpp (622,082 assertions):

• every table entry is recomputed with big-integer arithmetic;
• known values generated with Python, whose float() is correctly rounded;
• 200,000 random doubles round-tripped through to_chars;
• the 128-bit products and leading-zero counts are checked against references, with and without __int128.

Also checked outside the test suite: 6.5 million tokens compared with strtod, among them 60,000 exact halfway cases. There was no difference.

Benchmarks

tests/benchmarks: Apple M1 Max, Apple clang 21, -O3 -flto, C++11, median of 10 repetitions, before → after:

benchmark	change
ParseString/canada	−6.5%
ParseFile/canada	−8.3%
ParseString/floats	−8.1%
ParseFile/floats	−2.9%
every other Parse*	within ±2%

json::parse of canada.json in a separate process, best of 5: −8.6% (C++11), −7.6% (C++17).

Compile time (clang -O2): +0.7% for a translation unit that only includes json.hpp, +0.9% for one that also instantiates parse.

x86-64: not measured yet; the numbers will follow in a comment.

Public API

No change. Parsed values are the same, since both paths round correctly.

---

Written by Claude Code.

🤖 Generated with Claude Code

[nlohmann]

CI fixes for this PR (commit a4556e8):

• ci_test_gcc, ci_test_standards_gcc (23): -Werror=unused-result for CHECK_THROWS_WITH_AS(json::parse("1.7976931348623159e308"), ...) in unit-class_lexer.cpp (GCC's warn_unused_result ignores doctest's cast to void). The result is now assigned to a dummy json _, as elsewhere in the tests.
• ci_clang_tidy: abseil-string-find-str-contains on longer.find('.') == std::string::npos. The position is stored in a variable first.
• clang (16.0.6) [Windows]: infra. The MinGW download from GitHub returned HTTP 500. Not caused by this PR.

Verified with Homebrew GCC 16 using the CI's GCC_CXXFLAGS (the test builds and passes). The clang-tidy change touches only the reported line.

The fix was merged upward through the whole stack (merge commits only: #5618 to #5635).

— posted by Claude Code on behalf of @nlohmann