Update simdjson and fast_float

3rdparty/README.md

@@ -57,7 +57,7 @@
 
 ## fast_float
 - [![Upstream](https://img.shields.io/github/v/release/fastfloat/fast_float?label=Upstream)](https://github.com/fastfloat/fast_float)
-- Version: 7.0.0-482cc1f (until Jan 17, 2025)
+- Version: 8.0.0
 - License: MIT
 
 ## flatbuffers
@@ -218,7 +218,7 @@
 
 ## simdjson
 - [![Upstream](https://img.shields.io/github/v/tag/simdjson/simdjson?label=Upstream)](https://github.com/simdjson/simdjson)
-- Version: 3.11.5
+- Version: 3.12.0
 - License: Apache-2.0
 
 ## stb (stb_image)

3rdparty/fast_float/decimal_to_binary.h

@@ -93,8 +93,8 @@ compute_error(int64_t q, uint64_t w) noexcept {
   return compute_error_scaled<binary>(q, product.high, lz);
 }
 
-// w * 10 ** q
-// The returned value should be a valid ieee64 number that simply need to be
+// Computers w * 10 ** q.
+// The returned value should be a valid number that simply needs to be
 // packed. However, in some very rare cases, the computation will fail. In such
 // cases, we return an adjusted_mantissa with a negative power of 2: the caller
 // should recompute in such cases.
@@ -158,7 +158,8 @@ compute_float(int64_t q, uint64_t w) noexcept {
     // next line is safe because -answer.power2 + 1 < 64
     answer.mantissa >>= -answer.power2 + 1;
     // Thankfully, we can't have both "round-to-even" and subnormals because
-    // "round-to-even" only occurs for powers close to 0.
+    // "round-to-even" only occurs for powers close to 0 in the 32-bit and
+    // and 64-bit case (with no more than 19 digits).
     answer.mantissa += (answer.mantissa & 1); // round up
     answer.mantissa >>= 1;
     // There is a weird scenario where we don't have a subnormal but just.