Fix quadratic float parsing in next_bytes_is_float

[enomado]

Fixes #607.

Problem

Parser::next_bytes_is_float searches the entire remaining input for "..", but clamps the result to the current float-char run:

let raw_float_len = self.next_chars_while_from_len(skip, is_float_char);
let valid_float_len = self.src()[skip..]
    .find("..")                              // scans to EOF
    .map(|i| i.min(raw_float_len))
    .map_or(raw_float_len, |i| i.min(raw_float_len));

Since the result is .min(raw_float_len) anyway, every byte scanned past raw_float_len is wasted. In a document with no ".." in it — the common case — find scans to EOF for every number, making self-describing deserialization (ron::Value / deserialize_any) O(numbers × input_size).

This regressed in v0.12.2 with #602. Same benchmark, only the version differs (--release):

floats	v0.12.1	v0.12.2	slowdown
16 000	3.2 ms	335 ms	105×
32 000	6.4 ms	1 397 ms	218×
64 000	12.2 ms (×1.90)	5 645 ms (×4.04)	462×

Fix

Bound the search to the float-char run — the form any_number already uses a few lines above:

let valid_float_len = self.src()[skip..][..raw_float_len]
    .find("..")
    .map_or(raw_float_len, |i| i.min(raw_float_len));

Behaviour-preserving:

• A match at index >= raw_float_len was already clamped to raw_float_len, so not finding it changes nothing.
• A ".." cannot straddle the end of the run: that would require src[raw_float_len] == '.', but '.' is a float char (is_float_char) and would have been part of the run.

The now-redundant .map(|i| i.min(raw_float_len)) before .map_or(...) is dropped (map_or already re-applies the same min).

Result: linear again, 64k floats 5 645 ms → 27 ms (207×).

Tests

• All 453 existing tests pass, including the seven range tests from Add support for number ranges  #602.
• Adds tests/607_quadratic_float_parsing.rs, which asserts on scaling rather than absolute time so it stays meaningful on slow or noisy CI: the ratio is ~2 when linear, ~4 when quadratic, and the threshold (3.0) sits far from both. It bails out if the baseline is too small to measure.

I verified the test genuinely catches the bug: on the unfixed parser it fails with ratio 3.90, and it passes on the fixed one.

[juntyr]

Thanks for the catch and the fix!

[juntyr]

@enomado It seems like we might need to disable the test on the 1.64

[juntyr]

Or maybe it could work without the black box hint?

[enomado]

Went with your second suggestion — dropped the black_box hint instead of gating the test off 1.64, so it keeps running everywhere. That was the only real breakage: std::hint::black_box is only stable since 1.66, so the 1.64 MSRV job hit E0658 (the stable/nightly jobs were just cancelled by fail-fast). The .unwrap()ed cross-crate from_str::<Value> allocates, so the parse still isn't optimized away without the hint. CI is green now.