mirror of
https://github.com/vercel-labs/scriptc.git
synced 2026-11-06 08:23:19 +08:00
Malte UblandClaude Opus 5.5
882c87d425
Three shapes from pi's process/child helpers: 1. A cleanup arrow such as `() => process.off(signal, handler)` sits in @types/node's `Process`-returning slot. The lambda's ABI was decided from its inferred return type before the contextual void slot was consulted, so the arrow promised a `Process` value the lowering cannot produce and the registration fenced. `lambdaSignature` now takes the contextual void answer first; the adoption block further down already computes it, so every program that compiles today keeps its IR. 2. `child.off`/`removeListener` were unimplemented. They join the `child.on` family, are limited to the removable literals `spawn`, `exit`, `close` and `error`, and require the listener value that was registered — removal is by closure identity, scanning the registry from the end as Node does. New C runtime entry points `scr_child_off_spawn/_exit/_close/_error` release the entry and shift the tail. 3. `child.signalCode` reads `string | null` from the recorded exit signal, with `scr_child_has_signal_code`/`scr_child_signal_code` behind the same typed-union wrap as `spawnRes.signal`; the IR validator pins the `string | null` result. The process listener registration paths (stdin events, IPC message and disconnect, uncaughtException and uncaughtExceptionMonitor, unhandledRejection, warning, signals, exit) now accept any discarded expression, matching `child.on` — `resultIsDiscarded` rather than a bare expression statement — so `handlers.push(() => process.off(…))` compiles. Evidence: corpus 8412 (removal through `off` and `removeListener` for all four events, `signalCode` while running, after a normal exit, after a fatal signal and after a failed spawn, idempotent double removal) and the `node-types` fixture plus project-config test that pins pi's exact `() => process.off(...)` cleanup closure. Ambient declarations gain the `signalCode` property and the four `off`/`removeListener` overloads. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>