fix(json): parse big integer literals to correctly rounded doubles

[bobzhang]

Problem

lex_integer_end conflated "cannot be represented exactly in 2^53" with "out of double range": once the exact-integer accumulator overflowed SAFE_INTEGER_LIMIT (2^53 − 1), it returned the Number(Infinity, repr=...) sentinel immediately, never consulting strconv. The decimal/exponent path already falls back to strconv for correct rounding, so the same value parsed differently depending on spelling:

Input	Before	After
"1e19"	Number(1.0e19)	Number(1.0e19) (unchanged)
"10000000000000000000" (= 1e19)	Number(Infinity, repr=Some(...))	Number(1.0e19, repr=Some(...))
"9007199254740993" (2^53 + 1)	Number(Infinity, repr=Some(...))	Number(9007199254740992, repr=Some(...))
"9".repeat(400) (beyond double range)	Number(Infinity, repr=Some(...))	Number(Infinity, repr=Some(...)) (unchanged)

Consequences of the old behavior:

• parse("9007199254740993") == parse("99999999999999999999") was true — Eq compares only the double value, so every big-integer text collapsed into one equivalence class
• from_json : Double raised on values doubles represent fine (1e19 is exactly representable)
• No mainstream implementation behaves this way: JS JSON.parse rounds correctly; serde_json / Jackson / Python keep exact or correctly rounded values; raw-text preservation (which repr already provides) is the opt-in layer elsewhere (Go json.Number, serde arbitrary_precision, JSON.rawJSON)

Found by the QuickCheck property suite in #3995 — the naive parse(stringify(j)) == j property falsified in 30 cases and shrank to a bare big Number.

Fix

On accumulator overflow, fall back to @internal/strconv.parse_double for the correctly rounded value and keep the exact source text in repr, so stringify remains byte-lossless. The infinity sentinel now only applies to literals strconv itself rejects (genuinely beyond double range).

Structured as red/green commits:

1. test(json): failing tests encoding the desired behavior (json/big_integer_parse_test.mbt)
2. fix(json): the lex_integer_end fallback + updated expectations in lex_number_test.mbt (the out-of-range sentinel tests pass unchanged)

Validation

• Full repo suite: 7029/7029 passing
• moon fmt, moon info — no public API changes

Note

If this merges before #3995, the two-regime number-contract test there simplifies back to the universal parse(stringify(j)) == j property; I'll update that branch accordingly.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes JSON integer-literal parsing so that integer-shaped literals exceeding the exact-integer range of IEEE-754 doubles (above 2^53−1) fall back to @internal/strconv.parse_double for correct rounding, while preserving the original source text in repr for lossless stringify. This aligns integer-literal behavior with the existing decimal/exponent path and prevents large integer texts from collapsing to an Infinity sentinel unless they are genuinely beyond double range.

Changes:

• Update lex_integer_end to parse oversized integer literals via @internal/strconv.parse_double, reserving the infinity sentinel for truly out-of-range values.
• Add targeted regression tests for big integer literal parsing, equality behavior, and from_json : Double decoding.
• Update existing number lexer tests to match the new correctly-rounded behavior.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
json/moon.pkg	Adds core/double to test dependencies for new/updated tests.
json/lex_number.mbt	Implements the overflow fallback from exact-integer accumulation to correctly-rounded parse_double, preserving repr.
json/lex_number_test.mbt	Updates expected debug output for large integer parsing to reflect correct rounding + preserved repr.
json/big_integer_parse_test.mbt	Adds regression coverage for big integer literals (rounding, equality, from_json : Double, and out-of-range sentinel behavior).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[coveralls]

Coverage Report for CI Build 5822

Coverage increased (+0.001%) to 90.324%

Details

• Coverage increased (+0.001%) from the base build.
• Patch coverage: 4 of 4 lines across 1 file are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	17973
Covered Lines:	16234
Line Coverage:	90.32%
Coverage Strength:	169605.65 hits per line

---

💛 - Coveralls