moonbitlang / core / 6857

89%

push

github

refactor(json): factor the escape predicate and writer out of write_escaped

Review follow-ups:

- The "does this code unit need escaping" test is now one `#inline`
  `needs_escape_unit`, shared by `need_escape_scalar` and
  `write_escaped`, and the escape table is `write_escape`, so the loop is
  four lines and the escape set is defined once.
- The tail of the last run is written in the loop's `nobreak` branch
  instead of being returned and written afterwards.
- Runs are sliced with `exact_view` instead of the raw-offset `view`.
  Escaped code units are ASCII, so every run boundary sits next to an
  ASCII unit and never inside a surrogate pair of a valid UTF-16 string
  (MoonBit strings are always valid UTF-16; `@json.parse` rejects lone
  surrogate escapes). The escape quickcheck that fed `write_escaped`
  lone surrogate halves now generates valid UTF-16 that still puts
  surrogate pairs next to escapes.

Release, json/stringify_escape_bench_test.mbt (main / previous / now):

| bench                          | native             | js                 | wasm-gc            |
|--------------------------------|--------------------|--------------------|--------------------|
| strings slash escaped n=2048   | 262 / 200 / 164us  | 426 / 370 / 398us  | 282 / 260 / 274us  |
| strings quotes controls n=2048 | 227 / 183 / 145us  | 421 / 332 / 335us  | 267 / 247 / 251us  |
| 2KB prose, one newline, n=64   | 418 / 284 / 142us  | 847 / 265 / 234us  | 497 / 432 / 373us  |

(An `Option`-returning `escape_sequence` helper was tried first and was
8-15% slower than the previous version, `#inline` or not.)
Codex review (gpt-6-astra, high): "No blocking issues found in the two-commit
diff. Approved under the stated valid-UTF-16 contract." Its optional cleanup
(build the valid-UTF-16 quickcheck strings directly from a shared
`adversarial_unit`) is applied and was re-reviewed: "Approved; no findings."

Signed-off-by: Codex CLI <codex@openai.com>
Co-Authored-By: Claude Opu... (continued)

19 of 19 new or added lines in 1 file covered. (100.0%)

16609 of 18581 relevant lines covered (89.39%)

332855.9 hits per line