PerryTS/perry v0.5.1520 on GitHub

The release body is capped, and a tag left behind by a failed attempt no
longer wedges the job. create-release failed v0.5.1519 with
HTTP 422: body is too long (maximum is 125000 characters). The notes are
generated from changelog.d/, and this release carries 1505 fragments —
the first tag since v0.5.1220 on 2026-07-04 — producing 2.8 MB of notes,
22× GitHub's limit.
Two things made that worse than a simple failure. gh release create creates
the tag and then POSTs the release, so the 422 left v0.5.1519 pointing at
the right commit with no release attached. And the guard above it aborted
unconditionally on any existing tag, so every retry then died on the debris of
the first attempt — the job could not succeed again by any path.
Now: the body is truncated on a line boundary to 120,000 characters with a
pointer to changelog.d/ at the tag, and an existing tag is reused when it
points at exactly the candidate SHA (still a hard error when it points
anywhere else, which is the case the guard was written for).
This would have blocked every release with a large fragment backlog, not just
this one. Verified against the real 2.8 MB notes: the result is 120,221 bytes
and ends cleanly.
The release refuses to publish the npm wrapper until every platform package
is actually visible in the registry. npm can report a successful publish
that never lands: on 2026-09-10 it printed
+ @perryts/perry-linux-x64@0.5.1519, exited 0 and signed provenance into
sigstore, while leaving the version staged — invisible (404, absent from
the packument's time map) and un-republishable (E409 Cannot publish over previously staged version on every retry, including after an npm unpublish).
The wrapper's existing guard keyed on npm publish's exit status, so it was
satisfied by that false success and @perryts/perry@0.5.1519 shipped as
latest with a platform dependency that does not resolve on linux-x64. The
version could not then be completed from our side at all, and the release moved
to 0.5.1520.
Before the wrapper is published, each platform package is now confirmed present
in the registry (up to 5 minutes each, polling). The check reads the
packument's time map, which was the only signal that told the truth here:
npm view returned nothing and the publish exit status returned success for a
version npm had no record of. A package that never appears blocks the wrapper
and fails the job.
The failure mode this prevents is specifically the bad one. A publish that
fails loudly costs a rerun; a publish that half-lands puts a broken latest in
front of users and burns the version number, because npm versions are
immutable and the staged slot rejects retries.
Probe validated against live registry data, including the exact failing case:
the five packages that really published read visible, and the staged
linux-x64 reads not-visible.
The wait is a single 45-minute budget across all platform packages, not a
short per-package one. npm's own delay notice says a large upload "may take
longer than usual" and allows itself 24 hours, and the packages settle in
parallel — so a tight per-package timeout would fail the normal slow case
while adding nothing against the broken one. Timing out is safe and resumable:
the platform packages are already published, so a rerun skips them on matching
sha1 and waits again. Publishing the wrapper too early is the step that cannot
be undone, because npm versions are immutable.
Version bumped to 0.5.1520 after npm left v0.5.1519 half-published. npm
staged @perryts/perry-linux-x64@0.5.1519 and never finalised it, leaving the
version invisible (404, absent from the packument's time map) and
un-republishable (E409 — Cannot publish over previously staged version).
Six of the seven packages went public, including the wrapper, so
@perryts/perry@0.5.1519 shipped as latest with a platform dependency that
does not resolve on linux-x64.
0.5.1519 cannot be completed from our side while that staged version persists,
so the release moves to 0.5.1520. Nothing about the build was wrong: all 14
legs were green and the packed tarballs are reproducible — a rerun skipped
every already-public package on a matching sha1.
Worth recording, because it cost about 45 minutes of looking in the wrong
place: npm publish printed + @perryts/perry-linux-x64@0.5.1519 and "your
package is being processed", and signed provenance into sigstore, all while
npm held no record of the version. The check that distinguishes "processing"
from "never landed" is the packument's time map, not npm view — a
published version appears there immediately.
The release's tarball check now derives its expected set from the publish
manifest instead of a hardcoded 9. v0.5.1519 failed to publish after a
fully green 14-leg build (run 34438751300) with
Expected 9 exact npm tarballs; found 7.
Nothing was wrong with the build. When the musl legs were dropped pending
#9382, PLATFORM_PACKAGES in scripts/publish/constants.mts was correctly
trimmed to 6, so ALL_PACKAGES is 6 platforms + 1 wrapper = 7.
prepare-ci-packages.mts packed 7 and passed its own check against
ALL_PACKAGES — and then release-packages.yml's separate hardcoded 9
rejected the same set one step later. Two expressions of one fact, and only
one of them was updated. The publish step never ran, so nothing reached the
registry, no tag was cut, and the version was not burned.
The check now reads the manifest that the previous step generates from
ALL_PACKAGES, and matches by name rather than by count — a count cannot
say which package is missing, which is the only question worth asking when
this fires. A missing tarball now reports
manifest package(s) have no packed tarball: perryts-perry-linux-arm64-…tgz.
Count equality is still asserted so a stray extra tarball fails too, and a
manifest of fewer than two packages is refused outright.
Written with while read rather than mapfile so it runs on bash 3.2 and can
be exercised on a developer machine, not only on a runner. It was tested
against five cases before shipping — all present; one platform missing; a
stray extra; a too-small manifest; and the real-world shape with stale empty
npm/perry-linux-*-musl directories still on disk. A step that has already
failed one release does not deserve to be shipped untested a second time.
Note for follow-up: the doc comments in constants.mts still say "The 8
platform packages" and "All 9" above 6- and 7-element arrays. They are stale
in exactly the way that caused this, but correcting them touches a
non-plumbing path, so they are left for a normal PR rather than a release pin.
apt-get update no longer gates CI jobs on third-party mirrors we never
install from. GitHub's Ubuntu images ship Chrome and Microsoft apt sources,
and apt-get update exits non-zero if any source fails. On 2026-09-09
dl.google.com's chrome-stable index served a Hash Sum mismatch and
reddened the release tier three times running — 22 jobs in run 34383689667,
then Install clang and Install mysql client in runs 34384580491 and
34386043331. None of those jobs want Chrome.
Ten sites now do two things: the 7 apt-get updates in test.yml, the 2 in
release-packages.yml's build job (the release critical path), and
setup-llvm22.
1. Drop the unused sources by CONTENT, not filename. The first attempt
  removed google-chrome.list and changed nothing, because image
  ubuntu24/20260907.300 has moved these to deb822 .sources files. The log
  shows the rm running and Chrome being fetched 0.2 s later.
2. Let the install be the gate. apt-get update's exit status aggregates
  sources we depend on with sources we do not, so it cannot answer the
  question we care about. The update is advisory; the apt-get install that
  follows decides. That is why setup-llvm22 stayed green through all three
  outages while its neighbours failed — it already verified by reaching for
  what it came for.
The removal is written as an if rather than ... || true, because
scripts/gc_gate_wiring_check.py rightly rejects || true inside the
gc-stress jobs and cannot distinguish a benign swallow from a real one. An
if CONDITION is exempt from set -e, so the guard is safe under -e and
pipefail while suppressing nothing. Verified under both, including the
no-match and missing-directory cases.
Two things worth recording, because each cost a five-hour tier. The Chrome
repo returned 200 from a developer machine while runners kept failing, so
"it has cleared" was wrong twice — a third-party mirror's health has to be
judged from where the job runs. And matching by name rather than by cause
failed here for the third time in this workstream, after an apt pin glob
missed libllvm22 and a KNOWN_FAIL name list missed a renamed test.
compile-smoke classifies the #9470 tokio flake by ERROR SIGNATURE, not by
test name. The flake is a property of the auto-optimize build, not of any
particular test — it lands on whichever tokio-using wrapper the run routes
through — so a name list is always one test behind. That cost three cycles to
learn: KNOWN_FAIL held test_issue_340_axios_response_props and
test_issue_414_mysql_query_params, and run 34355138005 then failed on
test_issue_9310_mysql2_param_values with the identical error while both
listed entries passed.
A failure is now tolerated when its *.compile_error.log contains
bundle a DIFFERENT tokio compilation. That string comes from perry's own
linker refusing the link
(crates/perry/src/commands/compile/shared_tokio.rs), so it cannot be confused
with a genuine compile error.
Verified it does not blind the gate: a fabricated error[E0308] still fails,
and a failure with no log also fails — an unexplained failure is never
assumed benign. The root cause is fixed on main by "isolate shared-tokio
auto-opt graphs"; this pin predates it.
This is the second time in this campaign that matching by name rather than by
cause produced a one-item-short list (the other being the apt pin's package
glob, which missed libllvm22 and libclang1-22).
npm pack --json changed shape at npm 12; the publish parser now accepts
both. Release run 34335433079 failed with
npm pack failed for @perryts/perry-darwin-arm64@0.5.1519 after all fourteen
build legs had gone green — the furthest any attempt had reached. The pack
itself succeeded (exit 0, tarball written); only the parse failed:
```
npm 11:  [ { "filename": …, "shasum": … } ]                  ← array
npm 12:  { "@perryts/perry-darwin-arm64": { "filename": … } } ← object, keyed
```
packTarball did Array.isArray(parsed) ? parsed[0] : undefined, so npm 12
yielded undefined and the caller reported a pack failure that never happened.
It now accepts both shapes, and logs the raw payload when it cannot — the
original code discarded it, which is why a one-line shape change cost a full
release cycle to identify.
Verified against the exact npm CI installs (12.0.2): the old parser returns
undefined, the new one packs successfully; npm 11.19.1 still passes.
The publish job pins npm@11 instead of npm@latest. The step exists to
clear the 11.5.1 OIDC floor, but @latest silently opted the repo's most
privileged job (id-token: write) into every future npm major — and npm 12.0.2
duly broke it. @11 clears the floor by a wide margin. Moving to a new major
is now a deliberate act, with a note to re-check proof.mts against that
major's pack --json output.
await-tests can accept an already-validated ancestor's gate when the only
difference is release plumbing. test.yml does not build the glibc image,
read changelog.d/, or run release-packages.yml — so a candidate that
differs from a green ancestor only in those files is already covered by that
ancestor's full-suite-gate. Re-running a ~5 h tier to re-prove untouched code
is pure latency, and this campaign paid it four separate times over one
Dockerfile.
Fail-closed by construction:
- the file list comes from GitHub's compare API, computed from the commits
  themselves — never from a dispatch input;
- any path outside the allowlist keeps the exact-SHA requirement;
- an empty diff is refused, since it should be impossible here and would
  mean the comparison did not do what we think;
- .github/workflows/test.yml is deliberately not allowlisted — changing
  the tier's own definition must re-run the tier.
Allowlist: changelog.d/**, scripts/linux-*.Dockerfile,
.github/workflows/release-packages.yml.
Verified against the live repo before landing: on pin 3216910e19 the resolver
selects ancestor 49132f00cd (whose gate is green) because the diff is exactly
changelog.d/9665-…md + scripts/linux-glibc-2.31.Dockerfile. Sabotage-checked
in the other direction too — a single crates/** file, test.yml, Cargo.toml,
a path-traversal string, or an empty diff each force the exact-SHA gate.
The glibc-2.31 image now takes bullseye-security from a pinned
snapshot.debian.org timestamp. Bullseye is EOL and Debian is retiring it,
which broke this image three times in four days:
- run 34197616242 — Release file for .../bullseye-security/InRelease is expired (Valid-Until: Mon, 07 Sep 2026 21:13:04 UTC).
- run 34272956353 — with check-valid-until=no, the same suite began returning
  404 for .debs from some Fastly nodes (151.101.74.132) while serving 200
  from others. A CDN lottery.
- run 34293996179 — dropping the suite entirely then broke apt's resolver,
  because the pinned base image already carries security versions:
```
libc6-dev : Depends: libc6 (= 2.31-13+deb11u11) but ...u14 is to be installed
libssl-dev: Depends: libssl1.1 (= 1.1.1w-0+deb11u1) but ...u8 is to be installed
perl      : Depends: perl-base (= 5.32.1-4+deb11u3) but ...u5 is to be installed
```
archive.debian.org does not carry debian-security (404), so the only stable
source of those exact versions is snapshot.debian.org — Debian's timestamped
time-machine, immutable by design and immune to both expiry and CDN state.
Verified at 20260901T000000Z, both architectures: libc6-dev
2.31-13+deb11u14 on amd64 and arm64, plus libssl1.1 1.1.1w-0+deb11u8, perl-base
5.32.1-4+deb11u5, gpgv 2.2.27-2+deb11u3 — exactly what the pinned base image has
installed.
The timestamp is part of the reproducibility contract: bump it only alongside a
base-image digest bump, and re-check those versions when you do.
LLVM packages are pinned to apt.llvm.org, and apt retries are enabled.
Debian's bullseye-security genuinely ships LLVM 22 packages (clang-22,
libpolly-22-dev, …), so apt preferred snapshot's copies and tried to pull the
large LLVM .debs through snapshot — an archival service, not a throughput
mirror. It reset the connection (run 34314310247):
```
E: Failed to fetch .../libpolly-22-dev_22.1.8-1~deb11u1_amd64.deb
   Error reading from server. Remote end closed connection
```
An apt preference pinning origin apt.llvm.org at 1001 keeps the bulk on the
fast upstream mirror, leaving snapshot to serve only the four small base
packages it is actually needed for (libc6, libssl1.1, perl-base, gpgv).
Acquire::Retries=5 covers the remaining transient resets.
Note the dependency resolution itself was already fixed by the snapshot pin —
this run installed all base packages cleanly and reached the LLVM step, which
the previous three attempts never did.
The apt pin is scoped by ORIGIN, not by package-name glob. A first attempt
listed clang-* llvm-* libclang-* libpolly-* … and missed libllvm22 (no
hyphen after llvm) and libclang1-22 (libclang1-, not libclang-).
Those two then resolved to Debian's 1:22.1.8-1~deb11u1 while clang-22 came
from apt.llvm.org's 1:22.1.8~++2026…, versions that cannot satisfy each other
(run 34316491127). Package: * with Pin: origin apt.llvm.org is exhaustive
by construction, and safe because that origin publishes only LLVM packages.
Validated before pinning, via a stage-mode dispatch on a scratch branch
(run 34316715021): the entire build matrix passed — all six build legs
including ubuntu-24.04 (191 min) and ubuntu-24.04-arm (159 min), plus all
eight build-cross legs. await-tests bypasses the gate in stage mode, so a
Dockerfile change can be proven in one build instead of costing a full tier.
The glibc-2.31 image now builds from archive.debian.org only. Bullseye is
EOL and Debian is actively retiring it, which broke this image twice in four
days:
- run 34197616242 — E: Release file for .../bullseye-security/InRelease is expired (invalid since 14h 44min 50s); its Release carried
  Valid-Until: Mon, 07 Sep 2026 21:13:04 UTC.
- run 34272956353 — with check-valid-until=no added, the same suite started
  returning 404 for its .debs from some Fastly nodes (IP 151.101.74.132)
  while serving 200 from others. A CDN lottery, not a clean removal.
There is no archive fallback for it: archive.debian.org carries bullseye,
-backports, -proposed-updates and -updates, but not debian-security.
So the bullseye-security suite is dropped and everything comes from the
archive. Verified against
archive.debian.org/debian/dists/bullseye/main/binary-arm64/Packages: every
package this image installs is present — build-essential 12.9, cmake
3.18.4-2+deb11u1, curl 7.74.0-1.3+deb11u13, gnupg 2.2.27-2+deb11u2, libssl-dev
1.1.1w-0+deb11u1, libzstd-dev 1.4.8+dfsg-2.1, perl 5.32.1-4+deb11u3, pkg-config
0.29.2-1, xz-utils 5.2.5-2.1~deb11u1, zlib1g-dev 1.2.11.dfsg-2+deb11u2,
ca-certificates 20210119.
The trade-off is explicit: these are archived versions without later security
patches. That is acceptable for a build toolchain image whose only purpose
is linking against glibc 2.31 — it ships no runtime surface itself — and it is
the standard configuration for an EOL Debian base.
cargo-test-perry: timeout-minutes 120 → 180. Shard 8/8 ran 111 min
in run 33959469688 and then overran the cap in run 34230915868 — killed at
exactly 2h00m06s — costing a rerun on an otherwise-green tier. It passed on
that rerun, so this is headroom, not a hang. 180 keeps a genuine hang well
under GitHub's 360-min hosted-runner ceiling. That is the fourth cap in this
campaign sized for a smaller suite (doc-tests 119/120, simctl 54/60,
macOS ext build 361/360), which is why a headroom check belongs in CI.
The glibc-2.31 image no longer fails on expired bullseye metadata. Debian 11
is EOL, so nobody refreshes its Release files, and apt rejects them once
Valid-Until passes. The security suite's Release carried
Valid-Until: Mon, 07 Sep 2026 21:13:04 UTC and expired mid-release, taking
down both Linux legs of run 34197616242 with:
```
E: Release file for .../bullseye-security/InRelease is expired
   (invalid since 14h 44min 50s)
```
The packages themselves still serve 200 — only the metadata is stale — so the
fix is [check-valid-until=no] on the security suite, which the main line in
the same file has always had. Deterministic from here on, not a flake: an
expiry only grows.
Removed prime-macos-x86_64-cache. It existed solely to keep the macOS
x86_64 leg's ext-library step under GitHub's hard 360-min job ceiling, back
when that step took 304 min. Building the 40 ext packages in one cargo
invocation cut it to 12–22 min, which made the warmer pointless — while it
still sat on the critical path (build depended on it), burning up to 250 min
to prepare a cache for a sub-20-minute step. Measured at 285 min in run
33940039247. Removing it takes roughly 4½ hours off every release.
Confirmed alongside, in run 34197616242: Build native ext libraries (Unix)
took 18 min on macOS aarch64, and Verify ext archives share stdlib's tokio passed its first real comparison — the gate fails when it compares
zero archives, so a pass means it genuinely matched tokio-using ext archives
against stdlib's.
Fixed two set -e traps in the new tokio-coherence gate. The gate added
alongside the unified ext build could never run to completion: GitHub executes
run: steps with bash -e, and the step had two constructs that exit under it.
1. [ -z "$got" ] && continue returns 1 whenever $got is non-empty — the
  normal case, an archive that does bundle tokio — so -e killed the step
  there. Now a plain if.
2. tokio_of() is a pipeline ending in grep, which exits 1 when an archive
  bundles no tokio. With pipefail the pipeline carries that status,
  got=$(tokio_of …) inherits it, and -e killed the step on the first
  non-tokio archive. Now || true.
In run 33940039247 the macOS aarch64 leg failed at this step having printed
only stdlib bundles tokio-7be87cf38f2c1f6e and compared nothing — the
build itself was fine.
The original sabotage test ran set -uo pipefail without -e, which is
exactly why it passed locally and failed in CI. The test now runs under
bash -e: incoherent → fail, coherent → pass with checked > 0,
nothing-compared → fail.
Measured: the unified ext build works. On macOS aarch64, Build native ext
libraries (Unix) went from 304 min to 12 min, and the leg's real work from
291 min to ~30 (perry 6 + runtime 9 + panic-abort 3 + ext 12). The log
confirms built 40 ext packages in a single cargo invocation.
The release's ext-library build is one cargo invocation instead of 40. That
step is the release's duration: in run 33861357826 it took 304 min on
macOS x86_64 (killed at GitHub's hard 360-min cap) and 291 min on aarch64,
while Windows — which skips ext libs entirely — finished the whole leg in
35–54 min.
The cost was structural. The step ran 40 separate cargo build invocations,
each carrying -p perry -p perry-runtime-static -p perry-stdlib-static -p <ext>.
#7358 requires each wrapper be built alongside stdlib so their feature unions
agree — it does not require them to be built one at a time. A different -p
set per iteration is a different feature union, so each of the 40 largely
rebuilt the compiler, runtime and stdlib: ~7.6 min × 40. Naming all 40 in one
invocation satisfies the same constraint and builds shared dependencies once.
If the unified build fails it falls back to the per-package loop, keeping
the old best-effort property that a wrapper which cannot build on a host does
not fail the release.
New release gate: ext archives must share stdlib's tokio (#507/#7629). This
is what makes the change above safe to make. rustc names each codegen unit
…tokio-<metadata-hash>.tokio.<cgu>…, so the bundled tokio is readable from an
archive's member names — the same signal
crates/perry/src/commands/compile/shared_tokio.rs uses at link time. Two
tokio compilations in one binary means two independent
tokio::runtime::context::CONTEXT thread-locals: stdlib's runtime enters one,
the wrapper reads the other, and the program aborts at its first socket with
"there is no reactor running". The release now fails at build time instead.
The gate asserts its own subject was live: comparing zero tokio-using
archives fails, because Perry ships several (mysql2, http, ws, fastify), so
seeing none means the ext build produced nothing or the member naming changed —
either way the comparison verified nothing and must not read green.
Sabotage-checked on real archives: incoherent → fail, coherent → pass,
nothing-compared → fail.
The macOS x86_64 release leg no longer dies at GitHub's 6-hour ceiling. In
run 33861357826, build (macos-15-intel, x86_64-apple-darwin) was cancelled at
361 min — GitHub's HARD 360-min hosted-runner cap, which no
timeout-minutes can raise. One step accounted for it: Build native ext
libraries (Unix) ran 304 min (the three steps before it took 54 min
combined).
The cost is structural. That step builds 40 governed ext packages, each as
its own cargo invocation carrying -p perry -p perry-runtime-static -p perry-stdlib-static (#7358 requires that so features unify per wrapper). A
different package set per iteration means a different feature union, so each
one largely rebuilds the compiler, runtime and stdlib — ~7.6 min × 40.
prime-macos-x86_64-cache exists to absorb exactly this, but primed only
-p perry, warming none of those 40 feature unions. It now runs the same loop
into the same release-x86_64-apple-darwin shared-key cache the build leg
reads.
The loop is budgeted to 250 min of the job's 330-min cap on purpose: a job
killed at its cap is cancelled, which skips rust-cache's post save step, so
a timed-out prime warms nothing and the next attempt starts equally cold —
the same trap that made the simctl retries in runs 33709079451 / 33718460967
unwinnable. Stopping early lets the job end normally, which is what writes the
cache. It reports how many packages it primed.
Note this is margin, not a cure: macos-14 (aarch64) finished the same work in
291 min, only 69 min under the ceiling, so both macOS architectures run
against the cap. If the ext build keeps growing, the durable fix is sharding
that step across jobs so the 6-hour budget applies per shard.
compile-smoke's memory-stability step is temporarily advisory (#9659). The
target-collector architecture gates cannot pass as written: they require that
every cycle be a copying minor (not_attempted == 0,
ineligible_cycles == 0), while the workloads driving them call gc()
explicitly on a ~6.4 KB heap — and a manual gc() runs a full mark-sweep
unless PERRY_GC_FORCE_EVACUATE=1 (#6946).
Measured in run 33743461798: the five workloads without that knob reported
not_attempted on 100% of cycles, while async_promise_closures — the one
that sets it — copied 486,088 B and promoted 158,648 B and still fails the
first two assertions on 5 of its 10 cycles. So no workload passes, whichever
way target_gates_require_copied_minor points. The collector is healthy;
the gate's contract is wrong.
The step is continue-on-error: true until #9659 settles that contract. This
is knowingly a gate that cannot fail — the pattern CLAUDE.md warns about — and
it is scoped to this release. It also makes the whole step advisory, including
canaries and [gc-trace] workloads that currently pass, so read the step log
and the gc-evidence artifact rather than its green tick.
Also open in #9659 and unrelated to the above: old_page_forced_defrag reports
old_page_moved_bytes(80) > old_page_selected_live_bytes(32), a real
accounting inconsistency.
compile-smoke: #9470's tokio-coherence pair is FLAKY, and the STALE guard
is now advisory. Run 33626738093 compiled all 1391 files clean; run
33709074616 failed test_issue_414_mysql_query_params with
"the wrapper archive(s) bundle a DIFFERENT tokio compilation than the stdlib
archive" — with only workflow-file edits between the two trees. A STALE check
is only sound for a deterministic failure: for a flaky one a single green
run does not prove the entry is fixed. #9471 made it fatal, which cost a cycle
in both directions — a lucky run tripped STALE, and pruning the entries then
let the next unlucky run trip UNEXPECTED. The entries are restored and STALE
now emits ::notice::. The root cause is fixed on main by "isolate
shared-tokio auto-opt graphs"; this release pin predates it.
doc-tests: timeout-minutes 120 → 240. Its comment sized the cap against
"macOS 34 min end-to-end", but the leg now runs the full xcompile matrix: 119
min against the cap (run 33598905771), then an overrun (run 33626738093)
cancelled with its own doc-tests already reporting 30/30 passed. On the raised
cap it finished in 121 min — one minute past the old limit.
simctl-tests: timeout-minutes 60 → 120. Successful runs grew 42 → 45 →
54 min; two consecutive runs on one commit then hit the cap at 61 and were
cancelled (33709079451, 33718460967) before a third passed at 54
(33727755737). A cancelled simctl run fails release-packages' exact-SHA gate,
so that coin flip blocked releases outright.
compiler-output-regression: a quoted LLVM label now starts a new basic block.
native-region-proof failed packed_f64_loop_versioning with
hot_loops_no_runtime_calls: {"for.packed_f64_fast.body.54.i.epil": ["js_array_alloc"]}
on correct codegen. The named block holds no calls at all — it is a clean
scalar epilogue; the js_array_alloc belongs to the following block, which
builds console.log's argument array.
The block splitter matched labels with ^([A-Za-z0-9_.$-]+):(?:\s|$). LLVM
quotes any identifier outside its bare-name set, and #9337's specialized
functions carry a $, so the next label is emitted as
"perry_fn_…$spec_i32.exit":. That line starts with ", so it never matched:
no new block began and the quoted block's body was appended to the preceding
label, moving a call into an unrolled hot-loop epilogue. The mis-attribution
can only ever move calls into the preceding block, which is exactly the
false-positive shape observed.
extract_blocks / extract_blocks_with_functions now accept optionally-quoted
labels and quoted define names. Verified against the exact IR CI analyzed
(run 33598905771): 510 → 512 blocks, hot-loop count unchanged at 29, subject's
hot-loop runtime calls {"…epil": ["js_array_alloc"]} → {}. Sweeping every
workload in that artifact, packed_f64_loop_versioning is the only verdict
that moves, so no masked failure is exposed. The regression test is
sabotage-checked: reverting the pattern fails 2 of its 3 cases.

test: ignore the Linux-only GC deopt abort (#9482)

cold_callback_arms_resume_once_at_the_next_index aborts on ubuntu-latest
with panic in a function that cannot unwind inside the
force_evacuation=false GC fixture, blocking full-suite-gate and therefore
every release cut.

It is consistent on Linux (never observed green there) and passes 3/3 on
macOS at the same pin — so it is not a flake, and the macOS result proves
nothing about Linux. The test file is byte-identical to its state at the
2026-08-31 pin, but it never executed in that tier, so its age is unknown:
this is deferred to unblock a release, not shown to be pre-existing.

Diagnosis and the Linux repro are in #9482; re-enabling is a one-line change.

test(9249): opt the blocked-store case into strict mode (#9426 semantics)

reflect_define_property_non_writable_prototype_index_blocks_array_store
asserted a TypeError from a sloppy-mode script. #9426 made a rejected
array-element write throw only in strict mode — which matches node:

	output
Perry, with `"use strict"`	`TypeError 1 P`
Perry, as written (script)	`no error 1 P`
`node --experimental-strip-types`, same `.ts`	`no error 1 P`

Perry and node agree exactly, so the code is right and the expectation was
stale. The test's purpose — a non-writable inherited index BLOCKS the store —
is still worth keeping, so it opts into strict mode rather than weakening the
assertion to the sloppy no-op.

Array.from(str) no longer returns [] for a string containing a lone
surrogate.

Array.from("a\ud83db")   // was []   now 3 elements, node-identical

js_array_from_string_codepoints validated the payload with
std::str::from_utf8 and returned an EMPTY array on Err. Perry string
payloads are WTF-8, not UTF-8 — a lone surrogate is a legal payload, produced
by slicing a pair, by charAt, or by a chunked decoder — so any string
holding one made the whole conversion silently yield nothing. Whole-array
data loss with no error: the result was empty, not wrong-length.

The spread, for…of and [Symbol.iterator] forms over the same string were
already correct, which is what made this a wrong answer rather than a
consistent limitation. The walk now steps the raw bytes with the bounded
wtf8_step decoder the other iterators use, which yields one code point per
step and reports a lone surrogate as its own single-unit step. A part carved
out of a WTF-8 source is built through js_string_from_wtf8_bytes so it
keeps STRING_FLAG_HAS_LONE_SURROGATES — isWellFormed() on the element
still reports false, and JSON.stringify still escapes it as a broken
half.

The mapped form Array.from(str, fn) took the same walk and was empty too;
it is fixed by the same change and asserted alongside.

The rewrite also closes a pre-existing GC hazard the old loop carried: it
held a raw elements pointer and a borrow of the source payload across every
per-element allocation, so an evacuating collection could move both out from
under it. The walk now uses the RuntimeHandleScope discipline
string/split.rs established — root the source and the result, re-read the
source after every allocation, publish each element only after its write and
barrier — which is why this was left out of the earlier surrogate batch
rather than done as a one-line swap.

test-files/test_gap_9431_array_from_lone_surrogate.ts is byte-compared
against node and asserts .length plus every element's char codes across all
five iteration forms. Built from unfixed origin/main the same fixture
diverges on 18 lines.

A global regex scan no longer drops the empty match that sits where the
previous match ended — "a".match(/a*/g) is ["a",""], "a".replace(/a*/g, "<>") is "<><>", and the same for matchAll and every replace form.

"a".match(/a*/g)         // was ["a"]        now ["a",""]
"aXa".match(/a*/g)       // was ["a","a"]    now ["a","","a",""]
"ab".match(/b*/g)        // was ["","b"]     now ["","b",""]
"a".replace(/a*/g, "<>") // was "<>"         now "<><>"

ECMAScript's RegExp.prototype [ @@match ] loop keeps a zero-width match at
the previous match's end and then advances one code unit
(AdvanceStringIndex). Rust's iterators do the opposite: both
regex_automata's Searcher::try_advance and fancy_regex's
Matches::next_with — the latter documented as "adapted from the regex
crate … ignores empty matches immediately after a match" — discard it and
re-search one character to the right. Every global operation was built on
those iterators, so every one inherited the rule.

The reported symptom understated it. The rule fires wherever an empty
match lands on a previous match's end, not only at the end of the subject, so
interior matches were lost too: "aXa".match(/a*/g) was missing two of
Node's four elements, and "a1b22".match(/\d*/g) three of five.

One global_scan module now holds the ECMAScript loop, and every global site
goes through it: String#match, matchAll, replace/replaceAll with a
string replacement, with a $<name> replacement, and with a callback — on
both the linear regex lane and the fancy_regex lookaround/backreference
lane. regress, the third engine, already stepped one position past a
zero-width match, which is the ECMAScript rule; its iterators are used
unchanged, and a test pins that lane as the control. Regex::replace_all is
gone from the string-replacement path for the same reason — it runs the
crate's iterator internally.

The scan takes a starting byte offset rather than a slice, which also gives
matchAll the #9429 treatment: it used to search
&subject[lastIndex..], so a matchAll on a regex with a non-zero
lastIndex evaluated ^, \b and lookbehind against the wrong left edge.

test_parity_regex_replace_fn_lookahead diverged from Node because of
this, exactly as #9430 recorded — and the runner could not see it, because
that test is scored against a stored expected/…txt holding OK rather than
against Node. Its /[a-z]+|(?=\.)/g assertion asked for ["ab","cd"], which
is the Rust iterator's answer; Node has always produced ["ab","","cd"] and
thrown. The assertion now reads Node's answer, so both runtimes print OK.

Found while fixing, NOT fixed here: split by a pattern only fancy-regex
can compile does not run RegExp.prototype [ @@split ] at all — the fallback
walks find_iter and slices between matches. It therefore emits a trailing
"" the spec's q < size bound never reaches ("a,b,".split(/(?<=,)/) →
["a,","b,",""] vs Node's ["a,","b,"]) and splices no captured groups
("aXbXc".split(/((?<=a)X)/) → ["a","bXc"] vs Node's ["a","X","bXc"]).
That is a lane gap rather than a scan gap — the regex lane runs the spec
algorithm in spec_regex_split and is correct — so it is excluded from this
fixture with a comment, and the runtime test fancy_lookbehind_split
currently pins the wrong answer.

exec/test at a non-zero lastIndex now evaluate the pattern against the
whole subject instead of subject.slice(lastIndex) — ^, $, \b and both
lookaround directions get their real context back. No flag beyond g/y was
needed to see this:

const r = /^b/g;      r.lastIndex = 1; r.exec("ab")   // was "b",  now null
const l = /(?<=a)b/g; l.lastIndex = 1; l.exec("ab")   // was null, now "b"

The engine call sliced the subject at the start offset and then re-based every
reported range by the same amount. Offsets survived that round trip; assertions
did not. A slice invents context at its left edge — ^ and \b hold at
offset 0 of the slice, where the subject says they must not — and destroys it —
(?<=a) cannot see the character it needs, and (?<!a) therefore holds
everywhere. Under /m it was severe: a line-scanning while ((m = re.exec(s)))
loop saw ^ hold at every index, so it walked one character at a time and
never terminated on its own.

All three engines already expose a positional entry point documented to keep
the surrounding context — regex::Regex::captures_at,
fancy_regex::Regex::captures_from_pos and regress::Regex::find_from — and
each returns absolute offsets, so the re-basing arithmetic is gone rather than
adjusted. OwnedExecMatch's three constructors no longer take a
search_start_byte at all: with the parameter removed, handing an engine a
slice again would not compile. The sticky check moves with it, from
start() == 0 to start() == lastIndex.

Found while fixing, same function: lastIndex > length was not "no match"
(RegExpBuiltinExec step 12.a) but a search clamped to the end of the subject —
/a*/g with lastIndex = 5 on "ab" returned an empty match at index 2 where
Node returns null. The bound could not be expressed where it was being
checked: it is a UTF-16 code-unit comparison, and utf16_index_to_byte
saturates at the payload length, so the byte-offset guard it replaced could
never fire. That also matters for astral subjects, where the code-unit length
and the scalar count differ.

Pinned by six runtime tests — one per engine lane, plus the past-the-end bound
and the test routing — and by a fixture byte-compared against Node covering
^, $, \b, \B, lookbehind, negative lookbehind and lookahead at
lastIndex 0 / mid-subject / end / past-end, sticky and global, and seven
hand-driven exec sweeps that have to terminate.

Two of those sweeps need #9408 (landed in #9427) as well as this fix, and are
the reason to read the pair together: while ((m = /^/gm.exec("one\r\ntwo")))
walks [0, 4, 5] — Node's answer — only with both. With #9408 alone the loop
never terminates, because ^ holds at the slice's left edge at every index;
with this fix alone it stops early at [0, 5], because (?m) still sees LF
only.

Fixed

ES module top-level code is now lowered as strict code, which it always is.
```
// any .mts / .ts under "type": "module" -- an ES module, strict with no directive
console.log(this === undefined);                          // node: true   Perry: false (an object)

const a = [1, 2]; Object.freeze(a);
for (a[0] of [7]) {}                                      // node: TypeError   Perry: silent
```
ES2024 §11.2.2: a Module is strict mode code, with no "use strict"
prologue needed. Lowering already knows this —
LoweringContext::module_strict is computed from the file's module goal and
feeds current_strict, so every HIR node that carries its own strict flag
(PutValueSet, PropertyUpdate, IndexUpdate) was already right, which is
why a plain frozenObject.x = 9 at module top level threw correctly and this
stayed hidden.
Codegen could not see it. Module init is lowered as a synthetic function, and
FnCtx::is_strict_fn was hardcoded false for it at both
codegen/entry.rs sites (entry module and per-module __init), and again for
every outlined entry chunk in codegen/entry_outline.rs — whose comment said
so and asked the next person to match it. So every lane keyed on the
context's strictness rather than on a node-carried flag ran module top-level
code sloppy:
- Expr::IndexSet (expr/dispatch.rs passes ctx.is_strict_fn straight into
  index_set::lower) — the node a for head or a destructuring target with a
  computed member lowers to. A rejected for (frozenArray[0] of …) was a
  silent no-op.
- Expr::This (expr/this_super_call.rs) — module top-level this took
  js_implicit_this_get_sloppy and read the global object instead of
  undefined.
- delete obj.prop and delete proxy.key
  (expr/instance_misc1.rs, expr/proxy_reflect.rs), which route their
  [[Delete]] boolean through js_delete_result(strict).
The module's strictness now rides on the HIR module as Module::init_is_strict,
set next to ctx.module_strict at the top of lowering, and read by both
entry.rs sites and threaded into entry_outline.rs's chunk functions — a
chunk is module top-level code that merely moved into a function, so relaxing
its mode would reopen the same hole. It also joins the module's stable hash:
it changes emitted code, so a cached object from a sloppy compile must not be
reused for a strict module.
test-files/test_gap_9423_module_init_strictness.ts is a plain .ts, which
under this repo's "type": "module" package is strict-mode ESM in both
runtimes, so every write in it sits at module top level where the spec says
strict. It covers module this, an undeclared-name assignment, and rejected
writes through each lowering that reaches a store at module top level — static
name, computed key, for-of head (named and computed), destructuring target
(named and computed), array element, and arr.length — plus the over-throw
controls that must still succeed (sealed/preventExtensions writes to an
existing property, and the same for-of head and destructure on an unfrozen
receiver). Byte-compared against node 26.5.1. The sloppy control for the same
shapes is #9422's .cts fixture, which is a CommonJS script in both runtimes.

Fixed

A rejected strict arr.length = n now throws when length is non-writable
by descriptor, not only when the array is frozen.
```
"use strict";
const a = [1, 2];
Object.defineProperty(a, "length", { writable: false });
a.length = 0;   // node: TypeError   Perry: silent (a.length stayed 2)
a.length = 2;   // node: TypeError   Perry: silent  -- a same-value write is rejected too

const b = [1, 2]; Object.freeze(b);
b.length = 0;   // node: TypeError   Perry: TypeError (already correct)
```
ES2024 §6.2.5.7 (PutValue) calls Set(O, "length", n, Throw) with
Throw = IsStrictReference, and OrdinarySet consults length's own
descriptor and reports false before it looks at n — so a non-writable
length rejects even a write of the value it already holds.
js_array_set_length_strict recognised only ONE of the two ways length
becomes non-writable. It tested OBJ_FLAG_FROZEN, which Object.freeze sets;
an explicit Object.defineProperty(arr, "length", { writable: false }) records
the attribute in the descriptor side table without freezing the array, and
that shape fell straight through to the sloppy body — whose own non-writable
arm is a silent return, annotated "strict-mode throw is handled by the
caller's PutValue". This entry is that caller. The throw set and the no-op
set had drifted apart, and nothing tied them together.
The predicate is not new: array_length_is_non_writable is what
push/pop/shift/unshift have guarded with since test262
Array.prototype.{push,pop,shift,unshift}/set-length-*-non-writable — those
mutators perform the same Set(O, "length", …, true). js_array_set_length_strict
was the one such site not using it. It is now checked before the
zero-truncate fast path, so a write the spec rejects cannot reach a shortcut
that stores.
Scope, stated because the neighbouring cases look similar and are not fixed:
Object.seal and Object.preventExtensions leave length writable, so
they are not this rejection and do not throw here. Perry's handling of those
two is wrong in a different, non-strictness way — it refuses the length change
outright, in both modes, where node performs it (preventExtensions then
a.length = 5 gives 5 in node, 2 in Perry) — and a sealed shrink should reject
via ArraySetLength's deletion walk, which Perry does not model. Making the
strict entry mirror the sloppy body wholesale would have turned both of those
wrong answers into wrong TypeErrors, so it deliberately does not.
test-files/test_gap_9422_strict_object_store_strictness.cts is a .cts, so it
is a CommonJS script in BOTH runtimes, with a sloppy arm and a "use strict"
arm. BOTH ARMS ARE ASSERTED, across the seven rejection shapes — frozen,
sealed, non-writable own, non-writable inherited, getter-only own, getter-only
inherited, non-extensible — plus the computed-key, class-field, update and
array-length lanes, and the over-throw controls (sealed and
preventExtensions writes to an EXISTING property, and an inherited setter,
all of which succeed in both modes). Byte-compared against node 26.5.1.
Unit test: set_length_rejection_throws_only_in_strict_mode in
crates/perry-runtime/src/array/strict_store_tests.rs, beside #9394's
element_store_rejection_throws_only_in_strict_mode, asserting both arms and
the writable-length control.
What #9422 as filed claimed, and what is actually true. The issue reported
that "use strict"; const o = {x:1}; Object.freeze(o); o.x = 9; is silent in
Perry, and located the cause as codegen emitting
js_put_value_set(..., strict = 0) at every property-set site. Neither holds
on main. That two-line program throws correctly, and so does every other
ordinary-object shape tested above. The emitted IR shows why: the strict arm
lowers to js_class_field_set_fallback (which throws), while the two
strict = 0 literals in expr/property_set.rs sit inside
try_lower_sloppy_class_field_store / …_boxed_store, which
expr/proxy_reflect.rs reaches only under if !*strict — where strict = 0
is the correct constant. The array-length lane above is the one place a
rejected strict write really was silent.

Tests

test_gap_9421_async_output_flush pins the async queue-and-flush write
path that #9421 blames for the truncated claude-code transcript. It drives
multi-line output from async callbacks, a process.stdout.write loop,
interleaved console.log/console.error, output followed by an explicit
process.exit(), output past one pipe buffer, and a transliteration of
claude-code's own SessionWriter (scheduleDrain → setTimeout(100) →
await drainWriteQueue() → await appendFile, next to the one
appendFileSync record the report says is the only survivor). Perry matches
Node byte for byte in every one, including on unfixed main — so the
async-flush attribution is wrong. The writer-exit-early role reproduces the
reported 1-vs-5 signature exactly, under both engines, by leaving before
the 100 ms drain timer: the symptom identifies a run that ended too early,
not a flush that failed.

Fixed

A dynamic instance-method call no longer loses its receiver to the GC
(#9417). lower_call/property_get/dynamic_dispatch.rs lowered the receiver
first — JS evaluation order requires the MemberExpression to be evaluated
before the arguments — and then consumed it last, in the own-override probe,
the class-id tower and js_native_call_method. Every argument expression was
lowered in between, and an argument is arbitrary user code that can allocate.
A bare SSA register is not a GC root, so an evacuating young-gen minor inside
an argument left the receiver naming from-space.
Nothing faulted at the move. js_object_get_own_field_or_undef failed its
obj_type == GC_TYPE_OBJECT check on the recycled cell and answered
TAG_UNDEFINED, so the override probe missed and the by-name dispatch ran on
a retired address — the failure surfaced as a wrong answer several steps
downstream, naming a property unrelated to the defect. In the Claude Code
bundle that was Cannot read properties of undefined (reading 'def') on the
request-build path, from zod's ZodObject.extend; unauthenticated
--input-format stream-json went from 24/25 runs bad to 0/25.
Both dispatch sites in that file — the unknown-receiver-class path and the
known-class virtual tower — now root the receiver and every argument in one
RootedGroup and re-read below the group, the same combinator
early_branches.rs's computed-key dispatch (obj[k](…)) has used since
#7210. root_reload then re-derives each later use that a collection point
can reach. operand_protection still decides how each operand is protected,
so a provably non-pointer argument costs nothing.
test-files/test_gap_9417_dispatch_receiver_roots.ts reproduces the wrong
answer deterministically with no GC environment knobs, and
temp_root_coverage::dispatch_receiver pins the emission contract under both
root lowerings.

An accessor call no longer corrupts the caller's this across an evacuating
young-gen minor (#9417) — the defect behind claude-code answering
Cannot read properties of undefined (reading 'def') where node says
Not logged in · Please run /login.

invoke_accessor_getter / invoke_accessor_setter
(perry-runtime/src/object/field_get_set/accessors.rs) bind an accessor's
receiver by writing the GC-rooted IMPLICIT_THIS cell and keeping the previous
occupant in a bare Rust local for the duration of the accessor body:

let prev = js_implicit_this_set(eff_receiver);
let result = js_closure_call0(closure);   // USER CODE — allocates
js_implicit_this_set(prev);               // pre-collection address

The body is user code, so it allocates; a copying minor there relocates the
caller's receiver and rewrites every slot it can see — and a Rust local is not
one (#7249 / #7498). The restore then reinstalled a retired from-space
address as the caller's this. Two further locals in the same two functions
had the same shape: get_bits/set_bits across coerce_call_this's primitive
boxing, and the receiver plus the setter's assigned value across
clone_closure_rebind_this's fresh ClosureHeader allocation. All are now
rooted in a RuntimeHandleScope and re-read at their point of use.

Nothing crashed, which is why nothing caught it. A property read off the
retired cell reaches js_object_get_own_field_or_undef, which fails its
obj_type == GC_TYPE_OBJECT check and returns TAG_UNDEFINED rather than
faulting — so this.<field> silently answers undefined and the next member
access throws a TypeError naming a property several steps downstream of the
real defect.

How it was found. PERRY_GC_MOVING_LOOP_POLLS=0 and a large
PERRY_GC_SCAVENGE_NURSERY_MB both made the claude-code divergence vanish,
placing it on the evacuating minor; PERRY_GC_PROTECT_FROMSPACE=1 then faulted
on the exact stale use, and the backtrace off a PERRY_KEEP_SYMBOLS=1 build
read js_object_get_own_field_or_undef ← (JS getter frames) ←
invoke_accessor_getter ← builtin_reflection_accessor_read ←
js_object_get_field_ic_miss.

Test. test-files/test_gap_9417_accessor_this_restore.ts — an accessor
whose body allocates, called from a method that reads this afterwards. On
unfixed main it prints caller-this bad=30 with claude-code's exact message,
deterministically and with no GC env knobs; it is now byte-identical to
node --experimental-strip-types.

Not fixed here: the same unrooted let prev = js_implicit_this_set(x); …; js_implicit_this_set(prev) shape appears at ~18 other runtime sites (timers,
node streams, dgram, event_target, Map/Set forEach, promisify,
os_process_streams). iterator_helpers.rs is the one site that already roots
the saved value; the rest are the same latent hazard and want a follow-up
sweep.

Fixed

A program whose only pending work is a process.stdin read no longer exits
before the bytes arrive (#9416). process.stdin reached as an object — an
alias, a parameter, or a field — files its listener in perry-runtime's own
stdin registries; #9399 taught perry-stdlib's js_stdlib_has_active_handles
about those lists, but such a program links runtime-only, where the symbol the
generated event loop calls is perry-runtime's trampoline and the stdlib arm is
unreachable. The trampoline now consults stdin_listeners_keep_loop_alive()
itself, so stdin-driven filters, REPLs and stdio transports stay alive exactly
as long as Node keeps them (and no longer: pause()/unref()/destroy() and
EOF-plus-'end' still release the loop).

console.log / util.inspect no longer decode a class as an integer, a
sparse-array hole as NaN, or a settled promise as pending.

console.log(class Klass {})   // was "1"                  now "[class Klass]"
console.log(new Array(3))     // was "[ NaN, NaN, NaN ]"  now "[ <3 empty items> ]"
console.log(Promise.resolve(1)) // was "Promise { <pending> }" now "Promise { 1 }"

Three separate defects with one shape: a ladder classifies a NaN-boxed value
by tag, has no arm for the case in hand, and lets the bits fall through to
"must be a regular number".

A class value is an INT32-tagged NaN box carrying the class id, so every
else if v.is_int32() arm printed as_int32() — the raw id. INT32_TAG | 2
and a ClassRef with class_id == 2 are bit-identical; class_ref_id's
registry probe is the only thing separating them, exactly as
symbol/iterator.rs documents for for…of. Class ids are small and
sequential, so a program with N classes leaves the integers 1..=N
genuinely undecidable at the display ladder; perry now answers "class" for
those, because a class id leaking into output is never right. The probe stays
inside the is_int32() arm, where a value is already being turned into a
heap String, so ordinary numbers — plain f64 doubles — never pay for it.

TAG_HOLE's bit pattern is a NaN, which is why a hole printed as NaN
rather than crashing. Runs of holes now collapse to Node's <N empty items>,
and the single-line/multi-line decision counts the entries Node prints
instead of the array's length — new Array(7) is seven slots but one
entry, so it stays on one line. The same sentinel is why a tombstoned
Map/Set inspected wrongly: js_set_delete writes TAG_HOLE over the
slot and decrements size without touching used, so walking 0..size both
rendered the tombstone and stopped short of the live tail
(new Set([1,2,3]) after delete(1) printed Set(2) { NaN, 2 }). Both
walks are now bounded by used and skip holes, like the collection iterator
objects already did.

The promise arm was a hard-coded "Promise { <pending> }" string; it now
reads the state byte, and format_jsvalue_for_json gained the promise arm it
never had, so a promise-valued field says Promise { 1 } instead of
[object Object].

All three renderings live in one builtins/formatting/value_repr.rs shared
by the ladders in console.rs and formatting.rs, because a fix applied to
console.log and not console.error, or to format_jsvalue and not to
format_jsvalue_for_json (which renders the same array once it is an object
field), is a half-fix that reads as a working one.

One consequence had to be paid for: util.isDeepStrictEqual compares the
formatted rendering of two non-pointer operands, and two DISTINCT classes that
share a name now render identically where their class ids used to differ. A
class reference is therefore compared by identity in that tail — after
js_jsvalue_equals has already settled the equal case, so an ordinary integer
is unaffected.

The bit-identity collision turns out not to be observable through the display
ladders at all: a JS number is a plain f64 double and never reaches the INT32
arm. Measured with class ids 1 and 2 live, console.log(1), console.log(2),
[9].length, "A".charCodeAt(0) and 3 | 0 all still print integers. The
registry probe is the second line of defence, not the only one.

test-files/test_gap_9415_inspect_class_hole_promise.ts is byte-compared
against node. Built from unfixed origin/main the same fixture diverges on
34 of its stdout lines and on all 4 of its stderr lines.

Fixed

Number.prototype.toLocaleString no longer discards its locale and its
options bag. (1234.5).toLocaleString("de-DE") printed the en-US default
1,234.5 instead of node's 1.234,5, (0.5).toLocaleString("en-US", { style: "percent" }) printed 0.5 instead of 50%, and
(1e6).toLocaleString("en-US", { notation: "compact" }) printed
1,000,000 instead of 1M. There are 28 toLocaleString sites in the
claude-code bundle, so this was user-visible.
This was not a missing feature. Perry has a real ECMA-402
Intl.NumberFormat — new Intl.NumberFormat("de-DE").format(1234.5) already
produced node's bytes — and ECMA-402 defines
Number.prototype.toLocaleString(locales, options) as nothing more than
"construct an Intl.NumberFormat with exactly these arguments and
FormatNumeric the receiver with it". The arguments simply never got there.
They were dropped twice on the way:
- native_call_method/common_methods.rs answered every toLocaleString
  call — arguments or not — with js_object_default_to_locale_string, a
  helper that takes no arguments at all. BigInt already had a carve-out
  here (#5845) for exactly this reason; a number did not.
- object/primitive_proto_thunks.rs's
  number_proto_to_locale_string_thunk, the method that arm was shadowing,
  was itself declared (closure) with no parameters and called the
  hand-rolled en-US grouping helper unconditionally.
Both are fixed: a number receiver carrying an argument now falls through to
the prototype thunk (which also makes a user override of
Number.prototype.toLocaleString reachable), and the thunk is installed
rest-based so (locales, options) arrive and are handed to a real
Intl.NumberFormat.
This is also what made Array.prototype.toLocaleString look broken.
js_array_to_locale_string had been forwarding (locales, options) to each
element correctly all along; the arguments died one level below it, in the
element's own toLocaleString. [0.5, 0.25].toLocaleString("en-US", { style: "percent" }) is now node's 50%,25% with no change to the array
code.
The no-argument path is untouched and still free. (1234.5) .toLocaleString() never reaches the thunk at all — codegen folds the
zero-arg form to an inline js_number_to_locale_string call — and the
explicit toLocaleString(undefined, undefined) spelling is the same request,
so it takes the same branch rather than paying for a NumberFormat
construction. That matters because Intl has no formatter cache: every
argument-bearing call builds one instance, exactly as the spec describes.
Date.prototype.toLocale{,Date,Time}String now honors the locale for
dateStyle / timeStyle. d.toLocaleDateString("de-DE", { dateStyle: "long" }) printed September 1, 2026 — an English month name
in a German locale — and d.toLocaleString("ja-JP", { dateStyle: "full", timeStyle: "short" }) printed the en-US rendering.
Intl.DateTimeFormat.prototype.format (format_ms_with_dtf_obj) had already
been moved onto icu4x's CLDR patterns for these two options.
temporal_locale_string — the other spelling of the same operation, and the
one Date.prototype.toLocale*String delegates to — was left behind on the
bespoke format_date_style / format_time_style pair, which hard-codes the
en-US layout and the English month/weekday tables. The same instant with the
same options therefore formatted differently depending on which spelling was
used. The style arms now go through the same icu_style, keeping the bespoke
pair as the fallback for the combinations icu declines (a long/full
timeStyle carries a localized time-zone name) and for the Temporal partials
that own their own layout.
Affected files:
- crates/perry-runtime/src/object/native_call_method/common_methods.rs
- crates/perry-runtime/src/object/primitive_proto_thunks.rs
- crates/perry-runtime/src/intl/number_format.rs — new
  number_to_locale_string, the same make_instance +
  format_number_instance pair bigint_to_locale_string uses.
- crates/perry-runtime/src/intl.rs
- crates/perry-runtime/src/intl/date_collator/temporal.rs
Validation: test-files/test_gap_tolocalestring_locale_options_9414.ts
byte-compared against node 26.5.1 — de-DE / fr-FR / ja-JP / en-US and an
unknown tag; style percent and currency; notation compact short and long;
min/max fraction digits, minimumIntegerDigits and useGrouping; an
undefined locale with an options bag and an empty locale list; the
Date family with dateStyle / timeStyle / explicit field options and a
timeZone; Array.prototype.toLocaleString over numbers and dates; the
Intl.NumberFormat / Intl.DateTimeFormat rows that pin the delegation
target; and the no-argument calls as controls. Before the change 26 of its 64
lines diverged from node; after it, none.
Two pre-existing Intl gaps this delegation now exposes are deliberately NOT
pinned by that fixture, because each is wrong standalone — the fixture's own
Intl.* control rows prove it — and neither is a routing defect:
- Intl.NumberFormat groups in fixed 3-digit runs, so en-IN gives
  1,234,567.891 where node gives 12,34,567.891.
- A purely NUMERIC field set — which is the ECMA-402 default for
  Intl.DateTimeFormat and for a bare toLocaleDateString(locale) — is
  deliberately declined by icu_dtf::format_components (icu's Short length
  pads and truncates: 05.01.26, not node's 5.1.2026), and the caller's
  fallback assembly is hard-coded M/D/YYYY + h:mm:ss AM/PM. So
  new Intl.DateTimeFormat("de-DE").format(new Date(0)) is 1/1/1970
  instead of 1.1.1970. icu4x 2.2's FieldSetBuilder exposes alignment
  and year_style, which look like the right knobs (Alignment::Auto +
  YearStyle::Full on a Short YMD) — that is the follow-up.

Fixed

new Date("2026/09/01") is no longer Invalid Date. The numeric
slash-separated forms node accepts — "2026/09/01", "2026/9/1",
"09/01/2026" — all produced NaN in Perry. Every other date format tested
against node already matched, so this was narrowly the
implementation-defined-format branch of Date.parse / new Date(string).
ECMA-262 §21.4.3.2 deliberately leaves this format to the implementation, so
the new branch reproduces V8's measured behaviour, not a reading of the
spec. parse_date_string had exactly two grammars — ISO 8601 / MySQL and
RFC-1123 / month-name — and the second one requires a spelled month
(let m = month?;), so a purely numeric input fell out of both and returned
NaN.
The subtle half is not the acceptance, it is the time zone: unlike the ISO
branch, which is UTC, these components are LOCAL wall-clock time, so
new Date("2026/09/01").getHours() is 0 everywhere and the epoch value
differs per host. Getting that backwards would have looked like a working fix
in one time zone.
Behaviours reproduced from node (all measured, none assumed):
- Three numeric components are collected in order and padded with 1. If the
  FIRST is not a valid day-of-month (1..=31) the triple is Y/M/D, otherwise
  it is US M/D/Y — which is what makes "2026/09/01" year-first and
  "09/01/2026" month-first with no lookahead, and what makes "31/1/2026"
  Invalid (31 read as a month) while "12/1/2026" is 1 December.
- Two-digit years: 0..=49 → 2000s, 50..=99 → 1900s. "09/01/26" is 2026,
  "99/1/1" is 1999, "1/1/100" is literally year 100.
- The month must be 1..=12 and the day 1..=31, but a day past the end of
  its month ROLLS OVER instead of failing: "2026/02/30" is 2 March 2026 and
  "2026/09/31" is 1 October. "2026/13/01", "2026/09/00" and
  "2026/09/32" are Invalid Date.
- An optional clock with am/pm, fractional seconds, and GMT/UTC/Z/
  GMT±HHMM zone designators. 24:00 rolls to the next midnight; 25:00 and
  10:60 are Invalid. A bare +0500 is a zone only AFTER a clock has been
  read, which is why node's new Date("2026/09/01 +0500") is Invalid Date
  while "2026/09/01 10:30 +0500" is not.
- T is ISO-only: "2026/09/01T10:30" stays Invalid Date, as in node.
Affected files:
- crates/perry-runtime/src/date/parse.rs — new parse_slash_date, tried
  only after the two existing grammars and only when the input actually
  contains a /, so the ISO, MySQL, RFC-1123 and month-name paths are
  bit-for-bit unchanged.
Validation: test-files/test_gap_date_parse_slash_9414.ts — 60 rows covering
the three shapes, two-digit years, out-of-range and rolling-over components,
clocks, meridiem, zone designators, Date.parse, and ISO/RFC controls —
byte-compared against node 26.5.1. Before the change 41 of its lines diverged
(every slash row read Invalid Date); after it the output is byte-identical.
Host-zone independent by construction: local rows print the local getters plus
a delta from a locally-constructed reference instant, zone-designated rows
print toISOString().

Fixed

A class's compiler-internal identity no longer escapes into .name,
Function.prototype.toString, or util.inspect. Three separate leaks, all
of the same shape: a registration key or a class id that only the compiler
should ever see, handed to the program as a user-visible string.
1. .name reported the disambiguation key. Two class Made {} in sibling
  function bodies are distinct classes, so the second registers under a
  uniquified key (Made$0) to keep the name-keyed dedup from aliasing the two
  bodies onto one ClassId — see maybe_rename_colliding_class. That key
  reached js_register_class_name, so Made.name and
  new Made().constructor.name answered "Made$0".
2. A class expression constructed in place lost its name entirely.
  new (class extends Error {})("m").constructor.name answered
  "__anon_class_8" (node: ""), and even a named one —
  new (class Q {})().constructor.name — answered "__anon_class_6" instead
  of "Q". lower_new_non_ident lowers straight to a New on a synthetic
  key and never recorded the spec name, while its sibling
  lower_expr/arm_class.rs had recorded exactly that override
  (display_override) since #5592.
  Both are fixed by populating the existing Module::class_display_names
  override that codegen/string_pool.rs already prefers over the
  registration key. No new mechanism.
3. console.log(C) and util.inspect(C) printed the raw class id.
  util.inspect(Klass) answered 6. A class ref shares the INT32 encoding
  with a tagged small integer, and the console formatter's is_int32() arm
  printed the payload. It now renders node's form — [class Klass],
  [class Sub extends Named], [class (anonymous)].
String(C) / C.toString() now return the class's source text. They
returned function Klass() { [native code] }, which is not what node produces
for a class and not something a caller can parse. Perry already retained
function source (Module::closure_source_text, #4101) — the same
span-slice-at-lowering mechanism, keyed by ClassId, was simply never applied to
classes, which are the one callable kind that is not a ClosureHeader and so
cannot recover source from the closure registry.
Module::class_source_text is populated at lowering by slicing the module
source against ast::Class::span (SWC anchors it at the class keyword and
closes it at the body's }, so the slice is exactly the class's
[[SourceText]]), emitted by codegen as js_register_class_source, and read
by all three class-ref toString sites. A class with no registered source (a
builtin, or one perry synthesized) still gets the [native code] form, which
Test262's assertToStringOrNativeFunction accepts. Monomorphized
specializations inherit the origin's source, for the same reason #7632 makes
them inherit its name.
Affected files:
- crates/perry-hir/src/lower_decl/class_decl.rs — capture_class_source
  (the class sibling of capture_function_source), plus the display-name
  override for a renamed duplicate.
- crates/perry-hir/src/lower/expr_new/non_ident.rs — record the spec .name
  of an in-place-constructed class expression.
- crates/perry-hir/src/ir/module.rs,
  crates/perry-hir/src/lower/{context,lowering_context,lower_module_fn}.rs,
  crates/perry-hir/src/stable_hash/module.rs,
  crates/perry-hir/src/monomorph/driver.rs — the class_source_text map and
  its flush; it participates in the stable hash because it drives codegen.
- crates/perry-codegen/src/codegen/{string_pool,artifacts}.rs,
  crates/perry-codegen/src/runtime_decls/strings.rs — emit
  js_register_class_source.
- crates/perry-runtime/src/object/class_registry/class_meta.rs — the source
  side table, class_ref_to_string, class_ref_inspect_label.
- crates/perry-runtime/src/value/to_string.rs,
  crates/perry-runtime/src/object/native_call_method/common_methods.rs,
  crates/perry-runtime/src/object/global_this/array_error.rs,
  crates/perry-runtime/src/builtins/formatting.rs — the four read sites.
Not addressed, and still divergent: String(C.prototype.m) for a class
METHOD returns function () { [native code] } (node returns the method's
source). Class methods compile to perry_method_* symbols rather than
closures with a registered source, so this needs the method-side equivalent of
the closure source registry, not another read of this one. Object-literal
methods already work and are kept in the fixture as the control.
Validation: test-files/test_class_name_and_source_9413.ts (ESM) and
test-files/test_class_name_cjs_9413.cts (CommonJS, for the
module.exports = class {} spellings that get no NamedEvaluation), both
byte-compared against node --experimental-strip-types.

Fixed

A require() of a builtin no longer demotes process.nextTick below
promise microtasks.
```
require("path");                 // delete this line and perry matched node
const o = [];
process.nextTick(() => o.push("nextTick"));
Promise.resolve().then(() => o.push("p1"));
(async () => { await null; o.push("await"); })();
setTimeout(() => console.log(JSON.stringify(o)), 20);
// node:  ["nextTick","p1","await"]
// perry: ["p1","await","nextTick"]   (5/5 deterministic)
```
The deferral itself is correct, and measurement says so: the same file run
by node 26 as .cjs prints ["nextTick","p1","await"], as .mjs
["p1","await","nextTick"]. An ES module evaluates inside its module job's
promise chain, so its first tick drain lands after the promise queue — which
is exactly what js_mark_entry_module_esm (#788) models. It was being
applied to the wrong module kind.
Entry codegen decided "is this an ES module?" with
!hir.imports.is_empty() || !hir.exports.is_empty() || has_top_level_await.
A bare require( with no top-level import classifies the entry as
CommonJS, and cjs_wrap then rewrites it to ESM — injecting
import { createRequire as __perry_cjs_create_require } from 'node:module'
and export default _cjs. Both halves of that predicate became true for
every CommonJS program. The require("path") call itself contributes no
import at all; it folds to a native-module reference. Every real bundle
requires a builtin and every minimal fixture does not, so the ordering was
right in exactly the programs a test suite contains and wrong in exactly the
programs users run.
- crates/perry-codegen/src/collectors/cjs_scaffolding.rs —
  is_cjs_wrapped_module, keyed on the local name the wrap's synthetic
  createRequire import binds. Recognised from the HIR, not from an
  expectation about the template: if the wrap stops emitting it the
  predicate degrades to "not wrapped" (today's behaviour) rather than to a
  wrong answer for hand-written ESM, and a user's own
  import { createRequire } from 'node:module' is not mistaken for it
  because the match is on the alias, not the specifier.
- crates/perry-codegen/src/codegen/entry.rs — gate only the
  js_mark_entry_module_esm call on that. The is_esm_entry below it keeps
  its meaning for GlobalDeclarationInstantiation: a CommonJS module's
  top-level function declarations live inside the module wrapper and are
  not global-object properties either, so "not a Script" stays the right
  answer there — and that predicate is mirrored in perry-hir's
  lower_module_fn, which runs before the wrap flag is knowable in codegen.
- crates/perry/src/commands/compile/cjs_wrap/preamble_canary_tests.rs —
  a template canary in the same family as #7139/#7152: rename the local in
  wrap.rs and every CommonJS entry silently goes back to ES-module tick
  ordering with nothing going red. Plus a negative control, so the fix
  cannot drift the other way and give real ESM entries CommonJS ordering.
Validation: test-files/test_gap_9412_require_builtin_tick_order.cts
byte-compared against node — ticks first, a tick scheduled from inside a tick
joining the same drain, a tick scheduled from inside a microtask landing
after it, and a second event-loop turn where no evaluation checkpoint could
apply. It has to be a .cts: this repo is "type": "module", so a plain
.ts is an ES module for node and perry alike and cannot carry the shape
(#9418 taught the runner to discover .cts).
test-files/test_gap_9412_entry_tick_order.ts pins the ESM side so the fix
cannot be "stop deferring, always". Demonstrated failing on a compiler built
from unfixed origin/main.

Fixed

An Error subclass now has a .stack and reports [object Error].
class A extends Error {} produced instances whose .stack was undefined
and whose Object.prototype.toString tag was "[object Object]". The base
class was fine — new Error("x").stack has always been a string — so only
subclasses were affected, and the claude-code bundle has 93 of them and
106 .stack reads. claude doctor printed ~10 real frames and 14,573
bytes of stderr under node; under perry it printed - at <anonymous>
and 120 bytes. Silent: no error, just a missing trace.
One root cause behind both symptoms. class A extends Error {} deliberately
produces an ordinary GC_TYPE_OBJECT class instance rather than a
GC_TYPE_ERROR ErrorHeader, so that the subclass's own fields have
somewhere to live. alloc_error — the only place that fills
ErrorHeader.stack — is therefore never reached, and neither is any
stack on Error.prototype, which carries only name and message. The
[object Error] branch of js_object_to_string is keyed on that same GC
header byte, so a subclass fell through to the class_id block and out the
"[object Object]" default.
The class-id registry that answers this question already existed and was
wired at four other sites — instanceof Error, util.types.isNativeError,
Error.prototype.toString's subclass arm, and prototype-chain resolution
all consult extends_builtin_error(class_id). Neither the tag nor the stack
did.
- crates/perry-runtime/src/object/to_string_tag.rs — tag a
  extends_builtin_error class instance "Error", set before the
  Symbol.toStringTag hook so a subclass's own tag still wins (§20.1.3.6
  consults the tag property last).
- crates/perry-runtime/src/error_subclass_stack.rs (new; error.rs was
  within 90 lines of the 2,000-line CI cap) — js_error_subclass_capture_stack
  installs the own, non-enumerable, configurable stack accessor node
  installs, capturing the FRAME at the construction site. The head
  ("name: message") is formatted on read, not at capture, because that is
  what V8 does and what the ubiquitous
  constructor(m) { super(m); this.name = "X" } shape needs: node reports
  "X: m", and the assignment happens after super() returns. A user
  Error.prepareStackTrace still wins, as it does for
  Error.captureStackTrace. The setter redefines stack as a plain data
  property, so err.stack = "" keeps working.
- crates/perry-runtime/src/object/class_constructors.rs — install it from
  js_error_subclass_default_init (the synthesized standalone ctor, which
  also serves the dynamic-parent super path) and from
  default_error_init_for_implicit_chain (the dynamic new replay), the
  two runtime sites that already stamped message/name and stopped there.
  In the replay the install is moved above the message guard, which returns
  early for a no-argument new X() — exactly the instances that would
  otherwise still have no trace.
- crates/perry-codegen/src/expr/this_super_call.rs,
  crates/perry-codegen/src/lower_call/new_error_init.rs (new; the
  static-new Error arm moved out of new.rs, which was 5 lines from the
  2,000-line CI gate) — the same call from the two codegen sites that stamp
  message/name inline: an explicit super(message) into a built-in
  Error, and the static-new arm for a subclass with no own constructor.
  this is reloaded from its slot first; the stamps above it can collect.
A unit test in the new module installs the accessor under forced evacuation,
which is the only condition that can expose an unrooted pointer — and which
caught the first cut of that rooting reading a NaN-box handle back with
get_raw_const_ptr, aborting every Error-subclass construction with
"runtime handle kind mismatch". Nothing in the unit suite constructed an
Error subclass before, so only a compiled probe saw it.
Validation: test-files/test_gap_9410_error_subclass_stack.ts
byte-compared against node --experimental-strip-types across a bare
subclass, a this.name-assigning subclass, one with an extra field, a
two-level subclass, a subclass that sets message after an argument-less
super(), TypeError/RangeError subclasses, a factory-constructed
instance, a caught throw, Error.captureStackTrace on a subclass, and
controls for the base Error, a non-Error class and a plain object. The
fixture asserts the portable parts of the contract — typeof stack, the
head line, the toString tag, name/message/instanceof, and that
stack is an own but non-enumerable property that stays out of
Object.keys — because stack CONTENTS are host-specific. Demonstrated
failing on a compiler built from unfixed origin/main (46 diverging lines).

Fixed

split("") splits into UTF-16 code units, so an astral character yields
two parts (#9409). §22.1.3.23 runs SplitMatch over the code-unit sequence,
making "😀".split("") a two-element array of lone surrogates — matching
"😀".length === 2 and the halves charAt(0)/charAt(1) already returned.
Perry stepped its WTF-8 payload one sequence at a time, so an astral
character came back as a single part and every emoji-width, truncation and
column calculation built on split("") saw one unit where Node sees two.
Each half is now built with the same one-code-unit constructor charAt uses,
keeping the HAS_LONE_SURROGATES flag so isWellFormed() and
JSON.stringify still see a broken half; limit counts code units and may
legitimately cut a pair.

Fixed

^ and $ under the m flag now hold at every LineTerminator, not just
LF (#9408). ECMAScript §22.2.2.6 defines the multiline anchors over the
same four characters a non-dotAll . excludes — \n, \r, U+2028 and
U+2029 — but the translation leaned on Rust's (?m), which recognizes LF
alone. "one\rtwo".match(/^.*$/gm) returned null instead of
["one","two"], and CRLF (which is TWO terminators, with an empty line
between them) reported ["two"] instead of ["one","","two"], so any CRLF
markdown, git output from a Windows checkout, or /etc/os-release parse
silently mis-matched. The anchors are now spelled out against the same
LineTerminator set #9218 gave ., sharing one definition so the two cannot
drift; a multiline pattern with an anchor consequently compiles on
fancy-regex rather than the linear engine.

Fixed

A factory that returns class D extends <its parameter> no longer
SIGSEGVs when it is chained through its own previous result. The five-line
repro is zod v4's $constructor shape, the single most-used class factory in
the claude-code bundle:
```
function mk(P) { class D extends (P ?? Object) {} return D; }
const A = mk(null);
const B = mk(A);
console.log("ok " + typeof new B());   // node: ok object -- perry: SIGSEGV
```
One level was fine; the second level died, and only when the derived class
was actually instantiated. Not a regression — it reproduced identically on
83754818e (#9242) and a03be729c (#9336).
The recursion is a super() chain that never descends.
CLASS_DYNAMIC_PARENT_VALUE — the stash a compiled constructor's super()
leg reads back through js_get_dynamic_parent_value — is keyed by the
template class id and is last-wins, so one class evaluated N times leaves
exactly one heritage recorded. When that heritage is an earlier evaluation
of the same template, the parent's constructor re-reads the same entry,
resolves the same parent, and re-enters itself until the stack guard page.
Two lowerings reach it, and each needed its own half of the fix.
A non-capturing function-body class DECLARATION (no captures, no private
elements, no computed keys) keeps the shared-template lowering: it has no
per-evaluation class object at all, so mk(null) === mk(A) and the second
evaluation stashed ClassRef(D) against D itself.
js_register_class_parent_dynamic already rejects parent_cid == class_id
for the registry edge it writes ("so a recursive helper that returns its
receiver can't create a cycle"); the VALUE stash beside it did not. It does
now — a class is never its own superclass, and rejecting the write keeps
whichever heritage the earlier evaluation recorded, the only heritage a
single class id can describe.
A capture-carrying declaration or a class EXPRESSION does materialize a
distinct class object per evaluation, and each already pins its own heritage
(js_class_object_pin_parent) — the per-evaluation prototype chain and the
per-evaluation capture snapshot both read it from there. The super() leg
could not: a compiled constructor knows only its template class id, so it
asked the template stash and got the LAST evaluation's parent at every level.
new B(x) replayed B's constructor, resolved A, replayed A's constructor,
resolved A again, and looped. The constructor replay now names the evaluation
it belongs to for the duration of the call, and js_get_dynamic_parent_value
answers from that evaluation's pinned heritage when one is active.
Affected files:
- crates/perry-runtime/src/object/class_registry/evaluation_heritage.rs
  (new) — the self-heritage predicate and the active-replay frame, with the
  NaN-boxed class objects the frames hold.
- crates/perry-runtime/src/object/class_registry/parent_static.rs — reject a
  self-heritage stash write; split js_get_dynamic_parent_value into the
  per-evaluation override plus template_dynamic_parent_value, which
  js_class_object_pin_parent keeps using so a pin still records what the
  class DEFINITION evaluated.
- crates/perry-runtime/src/object/class_constructors.rs — push the frame
  around the class-object constructor replay, keyed on the same
  capture_owner object that supplies the constructor's capture params. The
  guard pops on unwind.
- crates/perry-runtime/src/object/class_registry/gc_roots.rs — the frames
  hold live heap pointers across a user constructor body, so the class
  side-table root scanner visits and forwards them.
Validation: test-files/test_gap_9364_factory_decl_dynamic_parent_chain.ts
plus byte-comparison against node 26.5.1 over 20 probes — both lowerings, one
/ two / three chain levels, an explicit super(), a rest-parameter
constructor, a declared-class parent instead of Object, static state on the
derived class, and the full zod $constructor shape (Object.defineProperty
on name, an initializer closure, instanceof). All previously-SIGSEGVing
probes now match node. perry-runtime 2895 passed / 0 failed. Five focused
unit tests cover the stash guard (including a ClassRef to a different class,
which must still be recorded) and the override (including that it answers only
for the replaying class's own template id, and that the frame pops); each half
was sabotage-checked — disabling the guard fails exactly two, disabling the
override fails exactly one. A 20,000-iteration construction loop over a
three-level chain runs clean under PERRY_GC_SCHEDULE_SEED=999 PERRY_GC_SCHEDULE_RATE=1 PERRY_GC_PROTECT_FROMSPACE=1 (20,005 copying minors,
20,000 loop polls, from-space mprotected), which is what exercises the new
root.
scripts/run_lint_gates.sh passes all 60 gates (including
gc_runtime_root_holders.py, which is what the new root has to satisfy). The
full gap suite reports 597/611 with 14 output mismatches; five are the
committed snapshot entries and the other nine reproduce on the pristine merge
base under the identical procedure — test_gap_6336_class_expr_builtin_parent
is reproduced there by adding two eprintln!s to perry-runtime and nothing
else, i.e. that host's ext-wrapper archives go incoherent on any runtime edit.
Two adjacent gaps are deliberately NOT addressed here and remain open. A
shared-template class declaration still collapses its evaluations, so
mk(null) === mk(A) reads true where node says false (and therefore
Object.getPrototypeOf(B) === A reads false); giving that shape a
per-evaluation class object is a lowering change with a far wider blast
radius than a crash fix should carry. Separately, a single evaluation of
class D extends (P ?? Object) { constructor(d) { super(d); this.d = d; } }
loses this.d — that reproduces unchanged on the merge base and is not
introduced or worsened here; the chained form used to SIGSEGV and now reaches
the same pre-existing wrong value.

Fixed

Inside a static body, this is no longer treated as an instance of the
class. class P { m() { return 1; } static probe() { return typeof this.m; } }
answered "function"; node answers "undefined". Worse than the typeof:
this.m() in a static body succeeded, running the instance method body with
the class ref as its receiver, where node throws a TypeError.
Two independent defects produced that one symptom, and each is reachable on
its own.
1. The codegen type predicates typed static this as an instance.
receiver_class_name(Expr::This) and static_type_of(Expr::This)
(crates/perry-codegen/src/type_analysis/predicates.rs) both answered
Named(class_stack.last()) in a static body exactly as they do in an instance
body. class_stack names the owning class in a static body too — that is what
super.x resolves against — but a static body's this is the class
CONSTRUCTOR: an INT32 class ref, never a heap instance. Every consumer of
those two answers was therefore entitled to prove instance facts about the
constructor object: instance field slots, shape ids, direct method dispatch.
Named(C) is not merely imprecise here, and "the constructor object of C"
would not have been a better answer: static members are INHERITED, so this
in a static body of Base is whatever subclass the call came through
(Sub.inherited() sees this === Sub, and Sub may override every static
member the body touches). None is the only sound answer, and it is what both
predicates now return under FnCtx::in_static_member.
This is what closes the alias residual #9386 documented and left open:
static viaLocal() { const t = this; … } reached the computed-member route
through guarded_declared_class_get_candidate, which reads local_types —
written by refine_type_from_init from static_type_of. With that predicate
honest the wrong type never enters local_types
(G.viaLocal(): undefined| → object|9).
2. The runtime's constructor-side property walk read C.prototype.
Declared instance methods are mirrored onto the reflective C.prototype
object as own data fields. resolve_proto_chain_field walks that object, and
the CONSTRUCTOR-side read in js_object_get_field_by_name (C.foo on a class
ref, after own statics and the static-method chain miss) called it — so every
prototype method resolved on the class object. This needs no this at all:
on dcf1ec0fbc, class P { m(){} } gave typeof P.m === "function" and
P.m === P.prototype.m, via the dot, computed, and Reflect.get forms alike.
js_object_has_property already had the gate ("m" in P was correctly
false), and the is_prototype_ref gate in the same file plugged this hole on
the direct-vtable door for #1021/NestJS — this is that door's chain-walk twin.
The receiver-less resolve_proto_chain_field has exactly one caller and it is
that static-side read, so the exclusion is applied there rather than at the
call site. It is keyed on class_instance_has_member — the exact "is this a
prototype method / getter / setter of the chain" predicate — and NOT on "skip
the decl-prototype entirely". A blanket skip was tried first and is wrong: it
also removes C.constructor, which the decl-prototype carries as an ordinary
data field. That answer is load-bearing today for a reason outside this issue:
perry hands a PROPERTY DECORATOR the class itself where the spec hands it
Class.prototype, so NestJS-style
Reflect.defineMetadata(k, v, target.constructor) relies on
C.constructor === C. Node says C.constructor === Function, so perry has two
divergences that cancel, and removing either alone breaks decorator metadata —
measured: test_decorators_nest_common_canary and
test_decorators_legacy_property_metadata both went pass -> parity_fail on the
blanket version. The decorator-target defect is the one worth fixing, and it is
not this issue.
The class_prototype_object step of the same walk is never skipped: for a
subclass of a class-EXPRESSION value it holds the parent CLASS OBJECT
(#1788/#6552), which is genuinely on the constructor's static chain.
Fixing only (1) would have left the issue's own example broken, and would have
moved one shape — const t = this; typeof t.computedMethod — from
accidentally-right to wrong, because it stopped taking the computed-member
route (which answered undefined for the wrong reason) and joined every other
instance-member read on the leaking generic path.
Affected files:
- crates/perry-codegen/src/type_analysis/predicates.rs — a guarded
  Expr::This if ctx.in_static_member => None arm ahead of each existing
  Expr::This arm.
- crates/perry-codegen/src/type_analysis_facts.rs —
  CodegenTypeFacts::this_type carries the same gate. Without it the generic
  HIR inference (infer_expr_type) re-derived Named(C) for every expression
  that merely contains this, routing around static_type_of's refusal.
- crates/perry-runtime/src/object/class_registry/prototype_objects.rs —
  resolve_proto_chain_field_inner takes skip_decl_prototype, set for the
  constructor-side form only.
No fast path is lost for the operations a static body actually performs.
Static field reads through this (this.sf), static method calls through
this (this.other()), this.prototype and this.name were already on the
generic class-ref dispatch: class_field_global_index never matched a static
field, and resolve_static_dispatch_cls has no Expr::This arm —
deliberately, because static inheritance means this in a static body cannot
be resolved to the declaring class at compile time.
Validation: test-files/test_static_this_is_not_an_instance_9404.ts,
byte-compared against node --experimental-strip-types, covering a static
method, a static block, a static getter, this === C, static-to-static
dispatch through this, the same on a subclass where this is the subclass,
the const t = this alias (plain and computed member), an instance-side
control, and a static method whose name collides with a String method.

Fixed

process.on("exit", …) handlers now run. They never ran at all: the
generated event-loop epilogue emitted beforeExit and then went straight to
cleanup, and nothing anywhere in the runtime ever emitted exit. The
process EventEmitter accepted the registration, kept the listener alive and
rooted it for the GC — the listener was simply never called, on any exit
path, with no error and no diagnostic.
This is silent data loss, not a cosmetic gap: exit is where a program does
its last synchronous flush. claude-code registers 17 exit handlers —
terminal-state restore, OpenTelemetry forceFlush, sandbox mount cleanup,
graceful-fs queue drain — and every one of them was a no-op under Perry.
Scope note, measured rather than assumed: the claude --bare -p hi
transcript that motivated this (1 line under Perry, 5 under node) does not
come from an exit handler and is not closed by this change. Snapshotting
the file from a prependListener("exit", …) under node shows all five records
already written before the first exit listener runs — they go through the
session writer's async insertQueueOperation / flush path, while the one
record Perry does write (last-prompt) is a direct appendFileSync. That
remains an open, independent divergence.
Node's exit sequence (handleProcessExit) is now one runtime function,
process::run_process_exit_sequence, driven from every path that ends the
process:
- crates/perry-codegen/src/codegen/entry.rs — the natural-drain epilogue
  calls it after beforeExit and its microtask drain.
- crates/perry-runtime/src/process/env_misc.rs — process.exit() runs it
  before terminating, and so does the fatal-path terminator
  exit_after_current_thread_collection_teardown (uncaught exception with an
  uncaughtException listener that rethrows, unhandled rejection).
- crates/perry-runtime/src/exception.rs — an uncaught throw with no open
  try runs it before printing its report, which is the order node uses.
  The listeners are JS, so the fatal branch was lifted out of the
  with_exception_state access it used to run under.
- crates/perry-runtime/src/os/os_process_emitter.rs — js_process_emit_exit
  does the emit itself, guarded to fire at most once. The guard is
  load-bearing: a listener may call process.exit() or throw, and node's
  answer to both is that the listeners after it never run.
The sync-only half of the contract needed no suppression machinery, only the
right splice point. Every caller terminates — or returns out of generated
main — as soon as the emit returns, and nothing past it ticks the timer,
setImmediate or nextTick queues, so a writeFileSync in a listener lands
while a setTimeout scheduled beside it is simply never given a turn. The
one piece of async work node does honour here is V8's microtask checkpoint
after the emit returns to the top level, so the natural-drain arm ends with a
promise-jobs-only drain: a .then queued by a listener runs, after every
listener, and only on that path.
Two smaller divergences in the same epilogue fell out of pinning it against
the oracle:
- beforeExit was emitted with a literal 0. Node passes the code the
  process is about to leave with, so process.exitCode = 5 made every
  beforeExit listener see the wrong number.
- The status a listener sets is now honoured. Node re-reads
  process.exitCode after the listeners run, on every path: a handler
  assigning 9 turns a natural exit, a process.exit(3) and an uncaught
  throw all into status 9. Perry exited 5 where node exits 9.
process.exitCode is published before the emit exactly where node publishes
it — an explicit process.exit(3), and the fatal paths, which force 1 even
over an already-set code — and left alone on natural drain and a bare
process.exit(), where a listener reading it must still see undefined.
Validation: test-files/test_gap_9403_process_exit_event*.ts — three
programs, one per process status (natural 0, explicit 3, listener-rewritten
9) — byte-compared against node 26.5.1, covering handler order, the code
argument and its arity, once / prependListener / removeListener,
beforeExit firing first and being skipped on an explicit exit, a
writeFileSync + read-back inside a handler, and setTimeout /
setImmediate / nextTick / promise jobs. On unfixed main all three
diverge — the natural-drain program prints 2 of node's 8 lines and the
exitCode program exits 5 instead of 9.
The fatal paths are pinned separately, against the same oracle: an uncaught
throw and an unhandled rejection each run the handlers with code 1 and let a
handler rewrite the status to 9; a handler that throws stops the ones after
it and exits 1; a handler calling process.exit(7) stops the ones after it
and exits 7. All five match node.
Compiled claude-code 2.1.112 exits 1 on --bare -p hi, as node does. Before
the companion optional-chain fix below it was SIGKILLed (137) — that is what
making the handlers reachable exposed.
perry-runtime --lib 2920 passed / 0 failed; perry-codegen --lib 1383 / 0;
perry-hir --lib 371 / 0.
An optional call on a ternary receiver did not short-circuit.
(c ? o : undefined)?.write(x) returned the RECEIVER when c held, and threw
TypeError: Cannot read properties of undefined (reading 'write') when it did
not, where node returns undefined in one case and calls the method in the
other.
A separate, pre-existing defect, filed here because the fix above is what made
it reachable: claude-code's very first process.on("exit") listener is
exactly this shape —
```
(process.stderr.isTTY ? process.stderr
  : process.stdout.isTTY ? process.stdout : void 0)?.write(resetSequence)
```
With both streams piped that value is undefined, so the listener threw, the
throw escaped process.exit() (node propagates it to the caller too), and
claude-code's try { process.exit(q) } catch { process.kill(process.pid, "SIGKILL") } fallback killed the process mid-shutdown. Status 137 instead of
node's 1.
crates/perry-hir/src/lower/lower_expr/arm_optchain.rs has a branch that
destructures a receiver's lowered Expr::Conditional and reads its condition
and then-branch as an optional chain's short-circuit test. It exists for
a?.b?.method(args), where the receiver really is a chain — but a ternary the
user wrote lowers to the identical shape, and the branch claimed it. Same
shape as #8090/#8109/#9403 above: a fast path claims the operation before the
question that distinguishes the cases is asked. Lowered shape cannot answer
"did a ?. build this?", so the receiver's AST is now asked instead
(transparently through parens and the erased TS wrappers).
Validation: test-files/test_gap_optional_call_conditional_receiver.ts,
byte-compared against node 26.5.1 — nullish tails in every spelling
(undefined / void 0 / null) and nesting depth, non-nullish tails that
must still CALL rather than return the receiver, property-read and
through-a-local controls, and the upstream-chain shapes the branch exists for
(a.b?.m(), a?.b?.m(), a?.b?.m?.()). Fails on the parent commit. The
standing optional-chain suite — #388, #4699 (both), #6719, #1111, #542,
test_optional_chain, test_optchain_builtin_method_call,
test_parity_optional_chain_double_member_call — is unchanged.

Fixed

A truncating consumer no longer kills a compiled program.
claude auto-mode defaults | head -2 exited 141 (128 + SIGPIPE) under
Perry and 0 under node — deterministically, 3 runs out of 3. Every pipeline
that stops reading early hit it: | head, | grep -q, | less followed by
q, a client that closed its socket.
The cause is structural rather than a mistake in any one function. A Perry
program has its own C main, emitted by codegen, so it never runs Rust's
std::rt startup — and that startup is where an ordinary Rust binary gets
SIGPIPE set to SIG_IGN. A compiled program therefore inherited the
signal's default disposition and died mid-write, with no JavaScript-visible
event and nothing to catch. Node (through libuv) ignores the signal and lets
the failing write(2) return EPIPE to the writer instead.
- crates/perry-runtime/src/os/signal.rs — ignore_sigpipe_at_startup()
  installs SIG_IGN, once per process, and only over SIG_DFL, so an
  embedder's own disposition and a later process.on('SIGPIPE', …) are both
  left alone. Unix only: Windows has no SIGPIPE.
- crates/perry-runtime/src/gc/mod.rs — called from js_gc_init, which is
  the first runtime call of every main / perry_module_init, so every
  compiled program gets it before a byte can be written.
Ignoring the signal alone would have traded exit 141 for exit 134:
std's println! turns the resulting EPIPE into a panic, and Perry builds
with panic = "abort". Node's console is specified never to throw
(node -e 'for(;;) console.log(1)' | head -2 exits 0), so:
- crates/perry-runtime/src/builtins/mod.rs — the console.* family's
  println! / print! / eprintln! are shadowed with writers that drop the
  write error, which is exactly that contract. The shadowing is confined to
  the builtins tree, alongside the pre-existing harmonyos hilog override;
  diagnostics elsewhere in the runtime keep std's macros.
Validation: test-files/test_gap_9402_sigpipe_truncating_consumer.ts
re-runs itself through bash, pipes 50 000 lines into head -2, and reports
the writer's status. Byte-compared against node 26.5.1: node
writer-status=0, Perry built from unfixed origin/main writer-status=141,
Perry with this change writer-status=0.
Known remaining gap, not addressed here: process.stdout.write swallows
the EPIPE (os_process_streams.rs has always discarded the write result),
where node emits an 'error' event on the stream and exits 1 if it is
unhandled. That is a stream-plumbing change, not a signal one.

Fixed

A non-UTF-8 byte in argv no longer aborts the process.
claude -p $'\xff\xfe\x80abc\xc3\x28' died with SIGABRT and a raw Rust
backtrace —
```
panicked at library/std/src/env.rs:878:51:
called `Result::unwrap()` on an `Err` value: "\xFF\xFE\x80abc\xC3("
```
— where node prints the program's own output. std::env::args() panics on an
argument that is not valid Unicode, and non-UTF-8 filenames are ordinary on
Linux, so this was trivially reachable by anything that passes a path
through.
Node decodes argv leniently: every invalid byte becomes U+FFFD. Verified
against node 26.5.1 — $'\xff\xfe\x80abc\xc3\x28' arrives as the eight code
points fffd fffd fffd 61 62 63 fffd 28, which is byte-for-byte
String::from_utf8_lossy.
- crates/perry-runtime/src/process.rs — one process_args_lossy() over
  std::env::args_os(), so a single bad byte cannot resurrect the abort in
  a path nobody thought to check.
Every std::env::args() reader in the runtime now goes through it. There
were nine, all reachable, and the panic was not confined to
process.argv:
- os.rs js_process_argv — process.argv;
- node_submodules/trace_events.rs — reads argv from js_gc_init, so
  the process died before a line of JavaScript ran, whatever the program did;
- process/permission.rs (×3) — the permission-model flag scan;
- process/report.rs (×2) — process.report;
- process/attributes.rs — process.title;
- cluster.rs (×2) — cluster exec-path defaulting;
- child_process/options.rs — self-launch detection in spawn;
- process.rs process_argv0_string — process.argv0 / execPath.
Three more outside the runtime, same shape, same fix:
- crates/perry-stdlib/src/commander.rs and
  crates/perry-ext-commander/src/lib.rs — program.parse() with no
  explicit argv;
- crates/perry/src/main.rs and crates/perry/src/update_policy.rs — the
  compiler CLI's own arguments, so perry compile on a non-UTF-8 path
  reports a diagnostic instead of a backtrace.
Not touched (UI crates, out of this change's scope): perry-ui-gtk4
src/tray.rs, perry-ui-macos src/app.rs, perry-ui src/bin/styling-matrix.rs.
std::env::var() needs no equivalent change: it returns Err for a
non-Unicode value rather than panicking, and the runtime has no
env::var(..).unwrap().
Validation: test-files/test_gap_9401_non_utf8_argv.ts re-runs itself
through sh (which is byte-oriented, so it can build an argument the source
file cannot contain) and prints the decoded length, code points and UTF-8
bytes. Byte-compared against node 26.5.1; Perry built from unfixed
origin/main reports child-status: null / child-signal: SIGABRT, and with
this change is identical to node.
process.stdin is now async-iterable: for await (const chunk of process.stdin) works, and typeof process.stdin[Symbol.asyncIterator] is "function" as in Node (#9400). The symbol was absent entirely, so the loop threw and any program driven that way produced no output. claude -p --input-format stream-json reads its message stream with exactly this loop, which is why it emitted nothing and still exited 0.
Fixed process.stdin 'data' chunks arriving as EMPTY Buffers (#9399). The chunk was allocated with buffer_alloc(len), which reserves capacity but leaves length at 0, and the caller never set it — so every un-encoded chunk reported .length === 0, toString() returned "" and Buffer.concat appended nothing. Only the setEncoding(...) string path was unaffected.
Fixed a process.stdin listener registered through an alias — const s = process.stdin, stdin passed as a parameter, or a field such as claude-code's this._stdin.on("data", this._ondata) — not keeping the event loop alive (#9399). Those registrations land in perry-runtime's own stdin listener lists, which no has-active check consulted, so the loop found no work and the process exited 0 with the pipe still open and the bytes unread. The liveness window now matches Node's: such a listener holds the process open until stdin reaches EOF and the buffered bytes have been delivered. Together with the empty-chunk fix above, this is why claude mcp serve answered nothing and exited 0.
Fixed JSON.stringify(value, replacer, space) crashing with SIGSEGV on an object whose property had been removed by an O(1) tombstone delete (#9398). The tombstone writes TAG_HOLE over the key slot and leaves the keys-array length alone; the replacer / pretty-print / array-replacer walks used the raw NaN-box bits of any non-string, non-pointer tag as a StringHeader pointer, so the hole was dereferenced. The plain no-replacer walk already skipped holes, which is why JSON.stringify(o) survived where JSON.stringify(o, null, 2) died. claude mcp remove <name> hit this on every run: it drops the server key and then rewrites ~/.claude.json with a 2-space indent, so the crash also left the server registered and the .claude.json.lock it had taken un-released.

Fixed

A rejected array element write no longer throws in sloppy code.
```
const a = [1]; Object.freeze(a); a[0] = 9;               // node: silent   Perry: TypeError
const a2 = [1]; Object.freeze(a2); a2[5] = 9;            // node: silent   Perry: TypeError
Object.defineProperty(a3, 0, {writable:false}); a3[0]=9; // node: silent   Perry: TypeError
Object.preventExtensions(a4); a4[5] = 9;                 // node: silent   Perry: TypeError
const o = {x:1}; Object.freeze(o); o.x = 9;              // node: silent   Perry: silent (correct)
```
ES2024 §6.2.5.7 (PutValue) calls Set(O, P, V, Throw) with
Throw = IsStrictReference, so a failed [[Set]] throws only in strict
mode — for an Array exactly as for the ordinary object that was already
right. A CommonJS bundle is sloppy code from top to bottom, which is where
this surfaced.
Introduced by #9326 (the merge of #9297, live again on main via #9370).
That change is right about what it set out to fix — an inherited accessor
must run, an inherited non-writable index must reject — but it reached the
rejection by routing the cold element-store continuation through the STRICT
runtime entry unconditionally. The inline store guard declines exactly the
receivers whose write can be rejected (frozen, sealed, non-extensible,
descriptor-bearing, prototype-sensitive), so every one of those shapes
arrived at that continuation and threw.
The fix carries the assignment's own Throw flag, which codegen already had
and already passes to the ordinary-object [[Set]] and to
js_dyn_index_set_strict. Finding the target is unchanged in both modes —
the #9220 inherited-descriptor walk still runs, so a prototype setter still
fires on a sloppy assignment; only the rejection differs.
- crates/perry-codegen/src/expr/index.rs,
  crates/perry-codegen/src/expr/index_set.rs,
  crates/perry-codegen/src/runtime_decls/objects.rs — pass the site's
  assignment_strict to js_typed_feedback_array_index_set_fallback_boxed
  and js_typed_feedback_array_set_index_or_string (one new trailing i32
  each).
- crates/perry-runtime/src/typed_feedback.rs — both helpers take that flag
  and dispatch on it.
- crates/perry-runtime/src/array/indexing.rs — the strict entry's body
  becomes strictness-parameterised (js_array_set_f64_extend_sloppy is the
  sloppy twin); array_spec_set takes Throw and returns the receiver
  unchanged instead of throwing when it is false. Array mutators keep
  Throw = true: their own algorithms specify it regardless of the calling
  code.
- crates/perry-runtime/src/array/indexing_keyed.rs — the same for the
  numeric/string-key dispatcher.
- crates/perry-runtime/src/value/dyn_index.rs — js_dyn_index_set_strict
  already carried the flag and its array arm forced true; it now uses it.
The realloc arm in expr/index.rs deliberately keeps the strict entry: it
runs only for a receiver the guard already accepted, which cannot reject.
Validation: test-files/test_gap_9394_array_element_store_strictness.cts
— a .cts file, so it is a CommonJS script in both runtimes, with a
sloppy arm and a "use strict" arm. Both arms are asserted. Asserting
only the throw is precisely what let this through: #9326 shipped with a
64-check differential and a 205-line gap fixture, all green, none of it
sloppy code. Byte-compared against node 26.5.1; Perry built from unfixed
origin/main reports TypeError for six sloppy cases where node is silent,
and with this change is identical to node. The #9326 fixture
(test_gap_9220_9221_array_proto_paths.ts, an ES module and therefore
strict) is unchanged and still byte-identical to node.
Unit tests, both arms: array/strict_store_tests.rs
element_store_rejection_throws_only_in_strict_mode, and #9326's own
typed_feedback_array_set_guards_reject_frozen_arrays, which now asserts the
silent sloppy call alongside the strict throw.
Three pieces of test infrastructure had to admit a .cts fixture at all —
each of which would have made it a dark test, green because it never ran:
- run_parity_tests.sh discovered the suite with find … -name '*.ts',
  which does not match foo.cts (the suffix is .cts). The fixture was
  invisible to the harness — confirmed empirically: --filter test_gap_9394
  selected 0 tests before the change and reports
  PASS test_gap_9394_array_element_store_strictness after it.
- the same script derived a test's name with basename … .ts, which left
  such a file called …strictness.c.
- .gitignore ignores test-files/test_* (compiled test binaries) and
  re-included only .ts / .tsx, so the fixture could not be committed.
Not addressed here, found while writing the fixture: Perry emits
js_put_value_set(..., strict = 0) at every property-set site, so a
rejected strict ordinary-object write ("use strict"; Object.freeze(o); o.x = 9) is silent where node throws. That is the mirror-image gap on the
object path and is out of scope for #9394.

Internal

Lands #9383's symbol Bloom-filter isolation, resolving its conflict with
the SymbolAddrRangeGuard::reset() workaround already on main in favour of
the stronger form: per_test_global! isolates SYMBOL_ADDR_FILTER alongside
the SYMBOL_POINTERS registry it guards, and the test plants the exact false
positive on a worker thread. The planted admission leaks through a
process-global filter and not through the isolated one, so the assertion has
a subject rather than merely not flaking (#9344).
Uses perry_thread_local! for CONCAT_MEMO. #9373 declared this hot
512-entry cache with a raw thread_local!, which check_thread_locals.py
rejects — the address should land in the thread's hot cache instead of
costing a _tlv_get_addr call (#7469). Its GC root scanner
(scan_concat_memo_roots_mut) is unaffected.

Fixed

util.inherits now accepts declared classes in either constructor slot.
Perry class constructors are tagged class references rather than closure or
object pointers; the runtime now stores the Node-compatible super_ property
on that representation instead of rejecting it as a non-object.
The prototype link installed by util.inherits is now observable from class
instances as well: inherited methods resolve through it, and instanceof
follows the linked prototype chain without creating an incorrect static
inheritance edge between the constructor objects. Regression coverage spans
all four function/class constructor pairings. (#9362)

Internal

Splits two object-module files back under the 2000-line cap. object/mod.rs
(1963) and object/tests.rs (1979) were each within ~35 lines of the gate and
#9367's transition-IC work took both over. The test-only side-table root
accessors and the transition-IC tests move to siblings, following the existing
own_key_probe_tests split.
Refreshes the shape-descriptor census. One new
object_header_size_bytes(ctx.target_triple) callsite in proxy_reflect.rs
(42 → 43) — the same fields_base = handle + header_size idiom already used
twice in that file — plus one keys_array access relocated by the split above.
Verified as exactly those two changes and nothing else.
Drops a redundant unsafe block in string/concat.rs that -D warnings
rejects.

Receiver hoists now use the shared safepoint-region model (#9254 phase 2).
The packed/versioned loop clone's rooted receiver box, pre-masked base handle
and poll reload recipe now live in one active descriptor entry instead of three
parallel FnCtx maps. Fired back-edge polls ask the shared boundary algebra to
admit every cached address before refreshing it, and nested clones reuse outer
descriptors without shortening their lifetime. Generated behavior is unchanged;
this is the first lowering consumer of the phase-1 model.

Fixed

The symbol Bloom-filter probe test no longer depends on unrelated tests'
filter population. Test builds now isolate SYMBOL_ADDR_FILTER with the
per-test SYMBOL_POINTERS registry it guards, while production keeps the
same process-global filter. A deterministic worker-thread false-positive
regression keeps the cross-test leak from returning.

Fixed and locked in module-global Buffer stores when the source index flows
through a ternary or conditionally reassigned local; both forms now match Node
instead of silently leaving the destination zeroed (#9278).

These notes are truncated. This release carries 1509 changelog
fragments and the full text exceeds GitHub's 125,000-character limit for a
release body. The complete set is in changelog.d/ at v0.5.1520.