Parent: #475 Depends on: #567, #568, #569, #570, #571, #575
Problem
Intl.NumberFormat.prototype.formatToParts and formatRangeToParts allocate fresh StringCell and backing copies for every type and source value. NumberFormat produces those metadata values from a closed specification-owned set, while only formatted value bytes require result-owned storage.
Exact-parent (9baffa8c) attribution at 100 jobs records:
- generic parts: checksum
14300800,281,594backing allocations /45,795,716bytes,244,280GC-cell allocations,6collections - generic range parts: checksum
61415241,673,706backing allocations /76,310,207bytes,636,393GC-cell allocations,15collections
The generic parts checksum matches system JSC. Range-parts attribution is measured against the exact parent because that broad mixed-style row is not the dedicated #570 differential oracle.
Scope
- Represent the closed NumberFormat part-type set with a native enum mapped to process-lifetime immutable string cells.
- Share the already-closed Intl range-source representation with DateTimeFormat.
- Replace internal part-type string comparisons with enum comparisons.
- Keep every formatted
valueindependently owned and preserve ordinary mutable part arrays/objects. - Preserve exact BigInt input, digit translation, range collapse, plural-range behavior, property order, and source attribution.
Acceptance
- Generic parts/range-parts checksums remain exact against the parent; dedicated NumberFormat differential controls remain exact against JSC.
- Attribution demonstrates fewer backing allocations/bytes and GC cells without increasing collections or property locks.
- NumberFormat and full Intl402 test262 subtrees have no regressions.
- Focused normal, TSan, OOM, moving-GC, bounded-heap, and no-GIL coverage pass.
- Full sharded units pass.
Exclusions
No Promise, microtask, Worker, queue, or job-lifecycle changes; those remain separately owned.