Negative `s64` import argument traps a ComponentizeJS guest with `unreachable` during argument lowering (positive `s64`, `s32`, and `u64`-with-bit-63-set are all fine)

[ryanhair]

Summary

A component built with ComponentizeJS traps with RuntimeError: unreachable
(wasm 'unreachable' instruction executed) whenever the JS guest calls an
imported function with a negative s64 argument. The trap fires inside the
guest's own core wasm module, during argument lowering, before the host import
body runs — the host never receives the value.

What traps and what doesn't (empirically determined, see the table below):

• Negative s64 (-1, -2, -2^63): TRAP, host never runs.
• Negative s64 as the second of two args (take-u64-s64(u64, s64),
  mirroring a real update-stock(item: u64, delta: s64)): TRAP, host never
  runs — the arg count does not change the manifestation.
• Negative s64 on a return-typed import (echo-s64(s64) -> s64): TRAP
  on lowering the negative argument; we never reach the return.
• Positive s64 (0 .. 2^63-1, including the max 9223372036854775807):
  clean.
• Negative s32: clean.
• u64 with bit 63 set (2^63, and 2^64-1 = all bits set): clean —
  the host receives the value. So this is specifically a signed s64
  lowering defect, not "any 64-bit value with the high bit set."

A Rust / cargo-component guest built against the identical WIT, transpiled
and run through the identical jco transpile --map + host.mjs, handles
every case cleanly — including take-s64(-2), the two-arg negative, and
echo-s64(-2) -> -2. So this is a 64-bit signed lowering bug in the
ComponentizeJS / StarlingMonkey guest, not "s64 is unsupported," and not a
problem with the WIT, the canonical ABI, or jco transpile.

Toolchain / environment

Item	Value
@bytecodealliance/componentize-js	0.21.0
@bytecodealliance/jco	1.24.3
cargo-component (parity control)	0.21.1
Node	v24.15.0
OS / arch	macOS (Darwin) arm64 (Apple Silicon)

Engine provenance: the JS engine is the prebuilt StarlingMonkey/SpiderMonkey
runtime bundled inside componentize-js 0.21.0. There is no separately
pinnable engine version — pinning componentize-js@0.21.0 pins the engine.

Repro layout

Save these files into one directory (e.g. s64-repro/):

s64-repro/
  package.json            # devDeps: componentize-js 0.21.0, jco 1.24.3
  world.wit               # the WIT below (shared by both guests)
  guest.js                # the JS guest
  host.mjs                # the host import implementation (logs what it receives)
  run.mjs                 # canonical runner (node run.mjs  |  node run.mjs rust)
  wit-rust/world.wit      # identical copy of world.wit for the Rust control
  rust-guest/             # cargo-component parity control (Cargo.toml + src/lib.rs; bindings.rs is generated)

npm install, then build + run from this directory. The component is
transpiled into out/ (and the Rust control into out-rust/); because the
generated modules live one level down, the host import is mapped to ../host.mjs.

WIT (world.wit)

package example:s64bug;

interface host {
  take-s64: func(x: s64);
  take-s32: func(x: s32);
  take-u64-s64: func(a: u64, x: s64);   // real shape: update-stock(item, delta)
  take-u64: func(x: u64);               // u64 high-bit probe
  echo-s64: func(x: s64) -> s64;        // s64 return path
}

world repro {
  import host;

  // single-arg s64 lowering (the original minimal shape)
  export run-neg-s64: func();      // take-s64(-2)
  export run-pos-s64: func();      // take-s64(2)
  export run-neg-s32: func();      // take-s32(-2)
  export run-max-pos-s64: func();  // take-s64(2^63 - 1)
  export run-min-neg-s64: func();  // take-s64(-2^63)
  export run-neg-one-s64: func();  // take-s64(-1)

  // two-arg shape (the real update-stock case)
  export run-u64-s64-neg: func();  // take-u64-s64(7, -2)
  export run-u64-s64-pos: func();  // take-u64-s64(7, 2)

  // u64 high-bit probe
  export run-u64-low: func();      // take-u64(2)
  export run-u64-bit63: func();    // take-u64(2^63)
  export run-u64-max: func();      // take-u64(2^64 - 1)

  // s64 return path
  export run-echo-neg-s64: func() -> s64;  // echo-s64(-2)
  export run-echo-pos-s64: func() -> s64;  // echo-s64(2)
}

JS guest (guest.js)

import { takeS64, takeS32, takeU64S64, takeU64, echoS64 } from 'example:s64bug/host';

export function runNegS64()    { takeS64(-2n); }
export function runPosS64()    { takeS64(2n); }
export function runNegS32()    { takeS32(-2); }
export function runMaxPosS64() { takeS64(9223372036854775807n); }   //  2^63 - 1
export function runMinNegS64() { takeS64(-9223372036854775808n); }  // -2^63
export function runNegOneS64() { takeS64(-1n); }

export function runU64S64Neg() { takeU64S64(7n, -2n); }
export function runU64S64Pos() { takeU64S64(7n, 2n); }

export function runU64Low()    { takeU64(2n); }
export function runU64Bit63()  { takeU64(9223372036854775808n); }   // 2^63
export function runU64Max()    { takeU64(18446744073709551615n); }  // 2^64 - 1

export function runEchoNegS64() { return echoS64(-2n); }
export function runEchoPosS64() { return echoS64(2n); }

Host (host.mjs)

Each host fn logs what it received, so we can tell whether the host body ran at
all before any trap:

export function takeS64(x) {
  console.log(`  [host] takeS64 received: ${x} (typeof ${typeof x})`);
}
export function takeS32(x) {
  console.log(`  [host] takeS32 received: ${x} (typeof ${typeof x})`);
}
export function takeU64S64(a, x) {
  console.log(`  [host] takeU64S64 received: a=${a} x=${x} (typeof a ${typeof a}, x ${typeof x})`);
}
export function takeU64(x) {
  console.log(`  [host] takeU64 received: ${x} (typeof ${typeof x})`);
}
export function echoS64(x) {
  console.log(`  [host] echoS64 received: ${x} (typeof ${typeof x}) -> returning it`);
  return x;
}

Build + run

npm install

# 1) build the JS guest component
jco componentize guest.js --wit world.wit --world-name repro --disable all -o repro.wasm

# 2) transpile, mapping the host import to the local logging module
jco transpile repro.wasm -o out/ --map 'example:s64bug/host=../host.mjs'

# 3) run the canonical runner
node run.mjs

run.mjs runs each case in its own child process and prints a per-case
CLEAN/TRAP verdict plus whether the host body ran. (Child processes are required
because a wasm trap permanently poisons the StarlingMonkey instance — every
subsequent call in the same process then also throws unreachable, and the trap
is additionally re-raised asynchronously as an uncaught exception. Isolating each
case gives an honest verdict and lets the runner exit 0.)

Observed output (node run.mjs) — exit code 0

JS / ComponentizeJS (StarlingMonkey) guest
module: ./out/repro.js   host import -> ../host.mjs

CASE                                               VERDICT  HOST-RAN?
---------------------------------------------------------------------
take-s64(2)              [s64, sign clear]         CLEAN    yes
take-s64(2^63-1)         [s64, sign clear, max pos] CLEAN    yes
take-s32(-2)             [s32 negative]            CLEAN    yes
take-s64(-1)             [s64 negative]            TRAP     no
take-s64(-2)             [s64 negative]            TRAP     no
take-s64(-2^63)          [s64 negative, min]       TRAP     no
take-u64-s64(7, 2)       [2-arg, s64 pos]          CLEAN    yes
take-u64-s64(7, -2)      [2-arg, s64 neg]          TRAP     no
take-u64(2)              [u64, bit63 clear]        CLEAN    yes
take-u64(2^63)           [u64, bit63 SET]          CLEAN    yes
take-u64(2^64-1)         [u64, all bits set]       CLEAN    yes
echo-s64(2) -> s64       [return, pos]             CLEAN    yes  returned 2
echo-s64(-2) -> s64      [return, neg]             TRAP     no
---------------------------------------------------------------------
13 cases, 5 trapped, 8 clean.
(HOST-RAN? = did the host import body log before the result? "no" on a TRAP
 means the trap fired DURING argument lowering, before the host ever ran.)

HOST-RAN? = no on every TRAP row: for the negative-s64 cases (single-arg,
two-arg, and return-typed) the host log never prints — the trap fires before
the host body runs. The two-arg case behaves exactly like the single-arg case
(trap during lowering); the argument count does not change the manifestation.

Raw trap (one negative-s64 call, no handler)

RuntimeError: unreachable
    at wasm://wasm/02fd7152:wasm-function[12600]:0x8be2b6
    at wasm://wasm/02fd7152:wasm-function[4756]:0x1ea6cf
    at wasm://wasm/02fd7152:wasm-function[4751]:0x1e9d99
    at wasm://wasm/02fd7152:wasm-function[5164]:0x225adf
    at wasm://wasm/02fd7152:wasm-function[5179]:0x23c909
    ...

The boundary is the signedness, not bit 63 alone: every value in 0 .. 2^63-1
is clean, every negative s64 traps, and a u64 with bit 63 set is clean
(2^63 and 2^64-1 both delivered to the host). The defect is specifically in
lowering a signed-negative s64.

Why this is the engine, not jco's transpile glue (ruling out the ABI / codegen)

The trap fires inside the guest's core wasm module
(wasm://wasm/...:wasm-function[12600] … the top frames are all wasm-function),
before the jco-generated import trampoline (_trampoline* in out/repro.js,
which is plain JS) ever runs — consistent with HOST-RAN? = no. The Rust control
uses the identical jco transpile --map 'example:s64bug/host=../host.mjs'
pipeline and the identical host.mjs, and is clean on all 13 cases. That
rules out jco transpile and the canonical ABI; the defect is the
ComponentizeJS / StarlingMonkey guest's signed-64 argument lowering.

Prior art

Searched existing issues. The closest, jco#1393 (fixed by #1421), is
about jco transpile --js (asm.js) codegen splitting i64 into i32 pairs — that
is a transpiler-codegen issue, unrelated to this engine-side s64 lowering
trap (which occurs with a normal jco transpile, not --js, and inside the core
wasm module itself).

Expected

Negative s64 import arguments should be lowered correctly and delivered to the
host (exactly as the Rust guest does), not trap the guest with unreachable.

Rust parity control (node run.mjs rust) — exit code 0, all clean

Same world.wit (copied to wit-rust/world.wit), a Rust guest via
cargo component build --release, transpiled and run through the identical
jco transpile --map + host.mjs:

Rust / cargo-component guest (parity control)
module: ./out-rust/rust_guest.js   host import -> ../host.mjs

CASE                                               VERDICT  HOST-RAN?
---------------------------------------------------------------------
take-s64(2)              [s64, sign clear]         CLEAN    yes
take-s64(2^63-1)         [s64, sign clear, max pos] CLEAN    yes
take-s32(-2)             [s32 negative]            CLEAN    yes
take-s64(-1)             [s64 negative]            CLEAN    yes
take-s64(-2)             [s64 negative]            CLEAN    yes
take-s64(-2^63)          [s64 negative, min]       CLEAN    yes
take-u64-s64(7, 2)       [2-arg, s64 pos]          CLEAN    yes
take-u64-s64(7, -2)      [2-arg, s64 neg]          CLEAN    yes
take-u64(2)              [u64, bit63 clear]        CLEAN    yes
take-u64(2^63)           [u64, bit63 SET]          CLEAN    yes
take-u64(2^64-1)         [u64, all bits set]       CLEAN    yes
echo-s64(2) -> s64       [return, pos]             CLEAN    yes  returned 2
echo-s64(-2) -> s64      [return, neg]             CLEAN    yes  returned -2
---------------------------------------------------------------------
13 cases, 0 trapped, 13 clean.

The Rust guest delivers every negative s64 correctly (including the two-arg and
the echo-s64(-2) -> -2 return path). Only the ComponentizeJS / StarlingMonkey
guest traps.

# build the Rust control:
#   (in rust-guest/)  cargo component build --release
#   jco transpile rust-guest/target/wasm32-wasip1/release/rust_guest.wasm \
#       -o out-rust/ --map 'example:s64bug/host=../host.mjs'
#   node run.mjs rust