wasm generation bug workaround, docs and debugging tips
This commit is contained in:
1 parent
7b1ba71ef0
commit
717a79aca2
5 files changed
+514
-788
No files matched your search
@@ -0,0 +1,15 @@
|
||||
# AI notes: avoid Kotlin/Wasm invalid IR with suspend lambdas
|
||||
|
||||
## Do
|
||||
- Prefer explicit `object : Statement()` with `override suspend fun execute(...)` when building compiler statements.
|
||||
- Keep `Statement` objects non-lambda, especially in compiler hot paths like parsing/var declarations.
|
||||
- If you need conditional behavior, return early in `execute` instead of wrapping `parseExpression()` with `statement(...) { ... }`.
|
||||
- When wasmJs tests hang in the browser, first check `wasmJsNodeTest` for a compile error; hangs often mean module instantiation failed.
|
||||
|
||||
## Don't
|
||||
- Do not create suspend lambdas inside `Statement` factories (`statement { ... }`) for wasm targets.
|
||||
- Do not "fix" hangs by increasing browser timeouts; it masks invalid wasm generation.
|
||||
|
||||
## Debugging tips
|
||||
- Look for `$invokeCOROUTINE$` in wasm function names when mapping failures.
|
||||
- If node test logs a wasm compile error, the browser hang is likely the same root cause.
|
||||
@@ -0,0 +1,27 @@
|
||||
# Wasm generation hang in wasmJs browser tests
|
||||
|
||||
## Summary
|
||||
The wasmJs browser test runner hung after commit 5f819dc. The root cause was invalid WebAssembly generated by the Kotlin/Wasm backend when certain compiler paths emitted suspend lambdas for `Statement` execution. The invalid module failed to instantiate in the browser, and Karma kept the browser connected but never ran tests.
|
||||
|
||||
## Symptoms
|
||||
- `:lynglib:wasmJsBrowserTest` hangs indefinitely in ChromeHeadless.
|
||||
- `:lynglib:wasmJsNodeTest` fails with a WebAssembly compile error similar to:
|
||||
- `struct.set expected type (ref null XXXX), found global.get of type (ref null YYYY)`
|
||||
- The failing function name in the wasm name section looks like:
|
||||
- `net.sergeych.lyng.$invokeCOROUTINE$.doResume`
|
||||
|
||||
## Root cause
|
||||
The delegation/var-declaration changes introduced compiler-generated suspend lambdas inside `Statement` construction (e.g., `statement { ... }` wrappers). Kotlin/Wasm generates extra coroutine state for those suspend lambdas, which in this case produced invalid wasm IR (mismatched GC reference types). The browser loader then waits forever because the module fails to instantiate.
|
||||
|
||||
## Fix
|
||||
Avoid suspend-lambda `Statement` construction in compiler code paths. Replace `statement { ... }` and other anonymous suspend lambdas with explicit `object : Statement()` implementations and move logic into `override suspend fun execute(...)`. This keeps the resulting wasm IR valid while preserving behavior.
|
||||
|
||||
## Where it was fixed
|
||||
- `lynglib/src/commonMain/kotlin/net/sergeych/lyng/Compiler.kt`
|
||||
- `lynglib/src/commonMain/kotlin/net/sergeych/lyng/Scope.kt`
|
||||
|
||||
## Verification
|
||||
- `./gradlew :lynglib:wasmJsNodeTest --info`
|
||||
- `./gradlew :lynglib:wasmJsBrowserTest --info`
|
||||
|
||||
Both tests finish quickly after the change.
|
||||
Reference in new issue
Block a user