mirror of
https://github.com/vercel-labs/scriptc.git
synced 2026-11-01 07:33:12 +08:00
Malte UblandClaude Opus 5.5
fc708251c3
The pack builds the ICU archive with the same Zig C++ recipe, adds scr_intl.c as an optional unit under the intl predicate, and publishes the archive under the id "icu". Its data file (icudt78l.dat) is not a link input: the pack lists it in a new manifest "data" array, and every Intl build copies it next to the executable it links (verifyArtifact checked, atomic copy, size-checked before reuse). A pack that omits scr_intl.c refuses an Intl program with SC3002 instead of linking undefined scr_intl_ references. The pack fetches both ICU inputs from the pinned release assets: the source tarball (verified, cached, unpacked by the system tar) for the archive, and the data zip (sha256 and size pinned twice) for the data, unpacked by a small stored/deflate reader. Nothing is embedded in a binary. The runtime fingerprint keeps covering the vendored trees, the pinned ICU version keys the archive path, and the pack matrix gains the icu archive with the intl predicate. The isolated native host (native/compiler.ts) links outside the in-process linker and writes its executables synchronously, so it installs the same data artifacts itself (installNativeRuntimeData); the stored pack selection gains a schema version so a selection cached before the data list existed is discarded rather than trusted. Nothing selects a data artifact for a program without the intl feature. The sanitized lane links the pack's ICU archive as shipped. ICU is C++ and compiles with Zig's C++ driver for the packs' glibc floor, so it cannot ride the sanitizer lane's per-TU C rebuild, and instrumenting ~600 C++ TUs would add a multi-minute build to the first Intl program in every sanitized lane. scr_intl.c itself still compiles instrumented with every other runtime unit, and AddressSanitizer's interceptors cover ICU's allocations. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>