CNA-BUG-262: CnaTests is linked with both -sJSPI=1 and -sASYNCIFY=1 on Emscripten; emcc lets the later flag win, so the JSPI its CMake comment relies on is silently replaced by Asyncify

CNA snapshot 009d40f5  ·  Known Issues › Current bugs  ·  source links pinned to 009d40f5

UnitTests.cmake adds -sJSPI=1 to CnaTests, but BuildPerformance.cmake then adds -sASYNCIFY=1 through cna_emscripten_asyncify; emcc keeps the later flag, so CnaTests is Asyncify-linked and the comment's reason (no Asyncify with wasm exceptions) is stale.

Identifier

CNA-BUG-262

Category

Bug

Subsystem

Build & CI

Status

Open

Verified against

CNA 009d40f5 (009d40f5dd085c4e674d3479675fac84b12b3e0a)

Severity

Low (a triage suggestion, not a project priority)

Evidence basis

Inferred (strong): follows from the code, but the behaviour was not run

Tests touching this area

None

Affected contract

CnaTests' Emscripten link options (cmake/UnitTests.cmake and cmake/BuildPerformance.cmake)

Expected behaviour

The comment in UnitTests.cmake says CnaTests is linked with JSPI, not Asyncify, so that it stays compatible with the Wasm exception ABI selected at the repository root (“Emscripten 6 explicitly rejects Asyncify mixed with -fwasm-exceptions”), and is run with node --experimental-wasm-stack-switching. A target that asks for JSPI is meant to be a JSPI build.

Actual behaviour at TARGET

CnaTests receives -sJSPI=1 as a direct link option in UnitTests.cmake and -sASYNCIFY=1 from the cna_emscripten_asyncify interface target that BuildPerformance.cmake attaches to every Emscripten executable not marked CNA_EMSCRIPTEN_ASYNCIFY OFF. CMake lists direct link options before interface ones, and emcc maps -sJSPI to ASYNCIFY=2 and then lets a later -sASYNCIFY=1 override it without a diagnostic, so the binary is an Asyncify build and the JSPI request has no effect. The root now selects the JS-lowered -fexceptions ABI rather than -fwasm-exceptions, so the comment's stated reason is also stale.

Source locations

• cmake/UnitTests.cmake — CnaTests' if(EMSCRIPTEN) link options: -sEXIT_RUNTIME=1 and -sJSPI=1 with the explanatory comment
• cmake/BuildPerformance.cmake — cna_emscripten_asyncify (-sASYNCIFY=1) and cna_apply_build_support_to_cna_targets

Evidence

Read at 009d40f5. The flag interplay was checked with the local emsdk (Emscripten 6.0.9, not the 6.0.3 CNA pins) and CMake 3.31.6 on a one-file probe outside CNA: -sJSPI=1 -sASYNCIFY=1 links without a diagnostic and produces the Asyncify output, -sASYNCIFY=1 -sJSPI=1 produces the JSPI output, and a CMake target with a direct -sJSPI=1 and an interface -sASYNCIFY=1 lists them in that order. CnaTests itself was not linked (the CI job that builds it cannot configure at TARGET, CNA-BUG-199), so the inference about its real link line rests on the CMake sources. Reported as unresolved by the D1 dismissal reviewer and settled by the orchestrator.

Focused reproduction

No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.

Regression test

Read the link line CMake generates for CnaTests (link.txt or compile_commands.json) under the web preset and assert that it contains exactly one of -sJSPI=1 and -sASYNCIFY=1; or mark CnaTests CNA_EMSCRIPTEN_ASYNCIFY OFF so that only JSPI applies.

Blast radius

The Emscripten CnaTests build only: it links as an Asyncify binary (larger and slower than JSPI) and the documented --experimental-wasm-stack-switching run flag is unnecessary. No shipped library or game target is affected.

Workaround

No workaround is known.