Two related fixes for Chrome-specific WASM-runtime issues reported when
running a manually-loaded session (line tool wouldn't even toggle on click;
log filled with 'Uncaught (in promise) unwind' and stderr-tagged
[WASM_FCONTEXT]/[DIAG_*] spam):
1) scripts/common/apply-asyncify.sh — run 'wasm-opt -O2' as a separate
pass after '--asyncify'. Without this, large asyncify-instrumented
coroutine-entry trampolines (notably libcontext's wasm_fcontext_entry
and COROUTINE<int,TOOL_EVENT const&>::callerStub) exceed V8's
per-function locals limit and silently stall on first fiber entry,
leaving the toolbar click dispatched in C++ but the tool never
activating its 'running=1'/[checked] state in the user's Chrome.
Firefox tolerates the unoptimised version, so tests on Firefox passed
while real Chrome stalled. The -O2 pass shrinks every instrumented
function back under the threshold, fixing the family of stalls
systemically (no more per-function removelist whack-a-mole).
The removelist still contains setupUIConditions() etc. as a safety
net — they're now redundant under -O2 but harmless.
Bundle: 338 MB -> 187 MB raw (~45% smaller); test runtime nearly
halves because parse is faster. See DEBUG.md §7 and
memory/bundle-size-asyncify-optimization.md.
2) wxwidgets submodule bump (d1d1627 -> a998a8d) — wasm/dialog.cpp:
startModal()'s setTimeout-based runEventLoop now awaits
ccall('ProcessEvents', ..., {async:true}) so the Promise rejection
from an asyncify-suspended ProcessEvents is caught by the existing
try/catch instead of escaping as an 'Uncaught (in promise) unwind'
page error.
Verified: npm run test:kicad:chrome and test:kicad:firefox both pass on
the rebuilt wasm; zero pageerror events; user-reported manual flow now
selects the Draw Lines tool and draws successfully.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
b5be072461