wasm runtime: post-parse hang — `object_get_dynamic` repeats indefinitely with identical args after keyword tokenizer enters its outer loop

[proggeramlug]

Summary

After working around #1034 (rt.date_get_day) and #1035 (__classDispatch arg padding), the editor's TS-side keyword tokenizer enters its outer per-line loop and hangs. DevTools console shows the runtime's mem_call: object_get_dynamic log line firing on the same array + same index over and over with no termination:

mem_call: object_get_dynamic args: 0,39,40,62,92,126,127,160,203,207,208,248,279,326,330,332,15 base: 65632
  result: 332 bits: 4074c00000000000
mem_call: object_get_dynamic args: 0,39,40,62,92,126,127,160,203,207,208,248,279,326,330,332,15 base: 65632
  result: 332 bits: 4074c00000000000
...

(repeating indefinitely; tab survives but never finishes, no error, no event loop progress.)

Environment

• Perry: 0.5.1006
• Target: web (--target web)
• macOS 26.4 (Darwin 25.4.0)
• Reproduced compiling @honeide/editor's perry/editor-component.ts. Hang occurs after CompositeEngine.parse(buffer) returns and the keyword scanner begins working on the document. Other targets (macOS, iOS) tokenize the same buffer without issue.

What we know

• The 17 args to object_get_dynamic look like a fixed array [0, 39, 40, 62, 92, 126, 127, 160, 203, 207, 208, 248, 279, 326, 330, 332] and an index 15. Result 332 matches arr[15].

• These numbers line up with byte offsets of | separators in the _KWS_TS keyword string in view-model/editor-view-model.ts, suggesting it's _KWS_TS.indexOf(...) or a related lookup inside a loop that never advances.

• The loop body in core/tokenizer/keyword-syntax-engine.ts:524:

  for (let ki = 0; ki < kws.length; ki++) {
    if (kws[ki] === word) { … }
  }

  …is plain TS that works on every other target. If the ki counter isn't being incremented in the WASM codegen, or kws.length is being re-read as a constant that prevents loop exit, that would explain the observation.

What I haven't done

• Bisected to a minimal repro independent of the editor — the suspicion is "for-loop with arr[idx] lookups in a class method on --target web" but I haven't proven it standalone. Happy to do this if useful; flagging early in case you recognize the pattern immediately.
• Run RUST_LOG=trace against perry-codegen-wasm to see what loop ops it emits.

Repro pointer

git clone https://github.com/HoneIDE/editor && cd editor
# Apply rt.date_get_day shim + __classDispatch arg-padding workaround
# (already wired in examples/web/build.ts on the web-architecture branch).
bun run examples/web/build.ts
python3 -m http.server -d examples/web/dist 8765 &
open http://localhost:8765/index.html
# DevTools console will show the repeating object_get_dynamic mem_calls.

If a focused repro would help, I'll reduce the keyword tokenizer to a standalone test case and attach.

Possibly related

• async function with await returns undefined on every call after the first #1029 (async-function-returns-undefined-after-first-call) is a different symptom but also in the dispatch path. Not obviously the same root cause; flagging for triage.

[proggeramlug]

Investigated alongside #1034 / #1035 in #1039. Built a minimal repro:

const kws = [0, 39, 40, 62, 92, 126, 127, 160, 203, 207, 208, 248, 279, 326, 330, 332];
const word = 332;
let found = -1;
for (let ki = 0; ki < kws.length; ki++) {
  if (kws[ki] === word) { found = ki; break; }
}
console.log('found:', found);

Compiles on --target web and runs to completion (found: 15), no hang. The pattern by itself doesn't reproduce — the hang has to be tied to something specific in how the editor constructs kws (.split('|') over the long _KWS_TS string, plus surrounding iterator state). Would help if you can reduce: take the editor's exact _KWS_TS literal + the exact construction of kws + the call path that reaches the loop, strip everything else, and confirm it still hangs standalone. Then I can run the codegen-wasm trace on a self-contained case.

Separately, the minimal repro surfaced an unrelated latent bug — toJsValue in wasm_runtime.js doesn't decode INT32_TAG and returns the raw f64 (NaN) for int32-tagged values, so kws[ki] === word returns false when one side is int32-tagged and the other a plain f64. Not the same as this hang; flagging as a separate bug worth filing.

[proggeramlug]

Reduction — narrow repro that doesn't depend on the editor at all

Following up on the request to strip down — here's the 7-line repro that exhibits the underlying bug:

// min1.ts
let result = '';
const depth = 0;
for (let i = 0; i < 16; i++) {
  result += String.fromCharCode(depth);
}
console.log('len:', result.length);  // expected: 16   actual: 144

perry compile min1.ts --target web --output min1.html, open in Chrome → console prints len: 144.

Variant matrix to pin down what triggers it:

Variant	Body of loop	Expected	Actual
result += 'x' (string literal)	result += 'x';	16	16 ✓
result += String.fromCharCode(0)	(as above)	16	144
result = result + String.fromCharCode(0)	(explicit +, not +=)	16	144
Same but loop runs 4× instead of 16×	…	4	36

So the pattern is precisely stringVar += <call-returning-string> (or the equivalent = + + form). The over-append is consistently 9× the actual char count. A bare string literal on the RHS works correctly.

Hypothesis

9 is the number of decimal digits in Perry's string-handle IDs. The codegen for the string-concat assignment is likely coercing the FFI return value (a NaN-boxed BigInt string handle) to its decimal string representation via String(bigint) instead of resolving the handle through the string table. Each iteration adds a fresh handle ID (e.g. "123456789") → 9 chars.

This would explain both:

• The exact 9× growth ratio (handle ID is a 9-digit integer in this build's stringTable),
• Why literal strings on the RHS work (the codegen for result += 'x' doesn't go through handle resolution; it can fold the literal directly).

Tie-back to the editor hang in this issue

The editor's buildBlockDepthString in core/tokenizer/keyword-syntax-engine.ts is shaped exactly like this:

let result = '';
let depth = 0;
const lineCount = buffer.getLineCount();
for (let i = 0; i < lineCount; i++) {
  result += String.fromCharCode(depth);  // ← the buggy line
  // … inner loops on buffer.getLine(i) …
}

With the 9× concat bug, result (which is supposed to be a 1-char-per-line cache used by every subsequent getLineTokens call) grows roughly 9× per parse. The mem_call: object_get_dynamic args: 0,39,40,62,…,332,15 log pattern in the original issue body is _lineStarts being indexed by downstream code that consumes this corrupted cache — the cache is never the right size, so the downstream loop keeps re-fetching the same end-of-buffer offset chasing a target it never reaches. That's the apparent "hang."

Where I think the fix lives

crates/perry-codegen-wasm/src/emit.rs — the codegen path for BinaryOp::Add (or compound assign equivalent) when both operands are typed as string and one is the result of a function call. It should call the string-concat runtime (which knows how to resolve handles → underlying string), not String(...) over the raw NaN-boxed value.

Happy to attach the full repro tree (min1.ts + variants var1..var4.ts + compiled .htmls) as a tarball if useful — let me know where to upload.

Possibly related

• The INT32_TAG decoding gap I noted in the previous comment (toJsValue not decoding int32-tagged values) is a separate-but-adjacent codegen bug. The two together suggest the value-encoding layer between WASM and JS deserves a focused audit — both bugs are in the "what does this NaN-boxed thing decode to when crossing the boundary?" code path.