ReviewOS

zig-utils/zig-js

Runtime: apply complete StrWhiteSpace in StringToBigInt

#749
Closed chris opened this 11 days ago ·
11 days ago

Parent: #473 Related: #459

Problem

The owned StringToBigInt paths trim only ASCII whitespace plus U+00A0 and U+FEFF. ECMA-262 StrWhiteSpace also includes U+1680, U+2000 through U+200A, U+2028, U+2029, U+202F, U+205F, and U+3000.

This makes the same valid string fail in every consumer of StringToBigInt:

BigInt("\u16801\u1680") // currently SyntaxError; must be 1n
1n == "\u16801\u1680"  // currently false; must be true
1n < "\u16802\u1680"   // currently false; must be true

The repository already owns a UTF-8-aware ECMAScript trim implementation (jsTrim/isJsTrimCp), so the BigInt grammar must use that single complete definition rather than another partial byte set.

Scope

  • Route BigInt construction and arbitrary-precision comparison through the complete ECMAScript WhiteSpace + LineTerminator trim set.
  • Cover all required code points on both boundaries, empty-after-trim input, decimal and radix forms, oversized BigInts, loose equality, and relational comparison.
  • Preserve invalid embedded whitespace and malformed grammar as failures.
  • Keep processing linear, allocation-bounded, and independent of host libraries.

No-workaround rules

  • No input-specific character list at call sites, ASCII-only shortcut, normalization, host Unicode/JavaScript engine, or relaxing whitespace inside the integer grammar.
  • Do not duplicate the trim table; use the owned canonical ECMAScript predicate/path.

Acceptance

  • Focused runtime probes pass for every ECMA-262 WhiteSpace and LineTerminator code point.
  • Constructor, loose equality, relational comparison, empty input, radix, and oversized BigInt cases share the same behavior.
  • Invalid embedded whitespace remains rejected/unequal.
  • Focused unit and test262 BigInt/equality subtrees have no regressions.
11 days ago

Landed c90be9e3 on main.

The fix removes the duplicate partial trim sets: BigInt construction/ToBigInt and loose/relational arbitrary-precision comparison now share one canonicalStringToBigInt grammar backed by the existing UTF-8-aware ECMAScript jsTrim/isJsTrimCp path.

Validation:

  • focused BigInt units: 17/17 pass;
  • new regression matrix: all 25 ECMA-262 WhiteSpace/LineTerminator code points across decimal, radix, empty, oversized, equality, relational, and embedded-whitespace rejection cases;
  • Test262 built-ins/BigInt: 77 -> 77 pass, 0 fail;
  • Test262 language/expressions/equals: 47 -> 47 pass, 0 fail;
  • Test262 language/expressions/does-not-equals: 38 -> 38 pass, 0 fail;
  • 0 Test262 flips and 0 regressions across those 162 cases.

Sign in to comment on this issue.