In `resume_vm`'s `restore_reuse`, the saved sp captured by
`call_closure_reuse` was ignored when restoring the caller frame after the
async callback finished. The suspended callee's locals/temps stayed on the
value stack above saved_sp, so subsequent LOCAL_GET/SET in the caller
frame (e.g. letrec sibling bindings waiting on the suspending call) read
stale callee data instead of their own slots. Sibling bindings appeared
nil after a perform/resume cycle on the JIT path used by the WASM
browser kernel.
Fix: after popping the callback result and restoring saved_frames, reset
`vm.sp <- saved_sp` (when sp is above), then push the callback result.
Mirrors the OP_RETURN+sp-reset discipline that sync `call_closure_reuse`
already follows.
New tests in `spec/tests/test-letrec-resume.sx` cover single binding,
sibling bindings, mutual recursion siblings, and nested letrec —
all four pass. Full OCaml run_tests: 4529/5868 (was 4525/5864), zero
regressions.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
In `call_closure_reuse`, the success path used a bare `pop vm` that relied on
OP_RETURN having left the stack at exactly `saved_sp + 1`. When the callee
returns a closure (or hits the bytecode-exhausted fallback path), `vm.sp` can
end up inconsistent with the parent frame's expected layout, corrupting
intermediate values such as parser combinator state in `parse-bind`/`many`/
`seq`.
Fix: read the result at the expected slot, then explicitly reset
`vm.sp <- saved_sp` before returning so the parent frame sees a clean stack
regardless of what the callee left behind.
OCaml run_tests baseline: 4525/5864 unchanged. WASM kernel tests: 24/29
unchanged. No regressions.
