Unify wasm-bindgen output under -sWASM_BINDGEN with marker-based detection

[guybedford]

This unifies wasm-bindgen output generation under a single -sWASM_BINDGEN path, building on the wasm-bindgen side change in wasm-bindgen/wasm-bindgen#5210. It supersedes #27179.

Previously -sWASM_BINDGEN was effectively a staticlib-only flow where emcc had to discover and own the export set itself. With wasm-bindgen/wasm-bindgen#5210, wasm-bindgen hoists its clean exported API (functions, classes, enums) into top-level library symbols that self-register as public exports via the __export/__force symbol attributes (#27436, wasm-bindgen/wasm-bindgen#5253) in its --js-library. The user-facing API now comes from wasm-bindgen's own library in every flow, so emscripten no longer needs to guess or own exports — it just surfaces what wasm-bindgen registered. That lets one -sWASM_BINDGEN path serve both whether cargo/rustc drives the link (bin crate, emcc as the linker, rustc supplies -sEXPORTED_FUNCTIONS) or emcc drives it (staticlib, exports discovered locally).

The model for a public export is the union across both systems: wasm-bindgen's self-registered API, plus emscripten's own EMSCRIPTEN_KEEPALIVE exports — minus wasm-bindgen's internal expansion glue, which must not spill into the public surface.

What's implemented:

• -sWASM_BINDGEN is a no-op unless the linker inputs carry wasm-bindgen's __wasm_bindgen_emscripten_marker custom section (emitted by the wasm-bindgen crate). The check runs on the inputs before the link (llvm-objdump --section-headers, so archive members are covered), so there is a single link and no speculative exports. When the marker is absent wasm-bindgen is never invoked and need not be installed, so cargo/rustc can pass the flag unconditionally via -Clink-arg without affecting ordinary builds.
• The exports the wasm-bindgen expansion reaches by name — the supplied EXPORTED_FUNCTIONS (method shims, the __wbindgen_* runtime, the marker, main) plus anything its expansion adds — are captured as internal glue and kept off every export layer: the ESM wrapper (user_requested_exports), the factory Module attachment (EXPORTED_FUNCTIONS, via should_export), and the keepalive pass in finalize_wasm. main still runs automatically on init; _main isn't surfaced.
• A genuine EMSCRIPTEN_KEEPALIVE C/C++ export is not in that internal set and remains surfaced, so a hand-written native export composes with wasm-bindgen's API in the same module.
• Placeholder symbols wasm-bindgen consumes (__wbindgen_describe*, __externref_*, ...) are stripped so they aren't reported as undefined exports.
• nm-based export discovery only runs when no driver supplied EXPORTED_FUNCTIONS; the rustc-driven link already lists them exactly.
• Imported JS is wired through: library_bindgen.extern-pre.js is fed as extern-pre-js and the snippets/ dir is copied next to the output so relative imports resolve.
• Under WASM_ESM_INTEGRATION, wasmExports is provided via a namespace import of the wasm so wasm-bindgen's by-name export access works. This is gated behind WASM_BINDGEN so plain ESM integration keeps per-symbol named imports and their tree-shakability. (The wrapper re-export of self-registered JS library symbols itself landed in Support JS libraries self-registering their exports with visibility attributes #27436.)

Both output modes then expose only the clean API (e.g. a Greeter class).

Testing:

• End-to-end test parameterized over the ESM (-sWASM_ESM_INTEGRATION) and factory (-sMODULARIZE -sEXPORT_ES6) output modes, built via cargo build with -sWASM_BINDGEN passed as a link arg, asserting the clean Greeter API works, main runs on init, and none of the raw wasm exports leak.
• A no-marker test asserting -sWASM_BINDGEN is a no-op for an ordinary hello_world.c build (doesn't require wasm-bindgen installed).
• The staticlib integration test is extended to assert an EMSCRIPTEN_KEEPALIVE native export survives alongside the wasm-bindgen API (fails under a blanket export wipe).
• CI installs a pinned wasm-bindgen-cli alongside rust so the flow is always exercised.

Not in scope (follow-up): preserving human-supplied EXPORTED_FUNCTIONS through wasm-bindgen linkage (the rustc-supplied set is currently indistinguishable from glue, so explicit exports aren't surfaced).

[guybedford]

@walkingeyerobot has now also confirmed that this unification approach works in his testing too.

[walkingeyerobot]

@sbc100 Sam, this looks good to me, but I'd appreciate it if you could give it a quick look before we hit the merge button. Thanks!

[guybedford]

This is now ready for final review.

[sbc100]

Can you remind my we wouldn't want to just make auto the default? i.e. make -sWASM_BINDGEN do nothing when the section tag is missing?

[guybedford]

@sbc100 I've added a further change here to remove -sWASM_BINDGEN=auto and just unify this as the default -sWASM_BINDGEN behavior, given the marker is always reliably found at this point.

[sbc100]

Does the commit message and description now need updating?

[sbc100]

What is this block doing? If WASM_BINDGEN is set but is_wasm_bindgen_module return false why do we need to then link again? Are the same wasm bindgen usages for which is_wasm_bindgen_module returns false still?

[guybedford]

Yeah this is a failure of the marker detection - the marker is not a symbol but a custom section, therefore finding it was requiring an initial link first.

This is clearly stupid yes, but was avoiding some of the other unnecessary steps previouslty.

I've added a third approach now using objdump to find the custom section marker instead. PTAL.

[sbc100]

Do you think one day we could remove get_wasm_bindgen_exported_symbols? Ideally these symbols would self-export? Maybe we could instead force any archive members that has_wasm_bindgen_marker to be included by the linker?

Doesn't need to be part of this PR, just wondering.

[guybedford]

The problem here is these are the core Wasm symbols usually reported by the Rust linker itself, based on visibility rules not present in the archive! Something that should be done better in the static case indeed. I haven't investigated deeply, but having Rust better align with C++ visibility conventions for Wasm sounds sensible to me, I wasn't involved in these original decisions.

[sbc100]

This change seems to be causing some tests to fail in CI. See https://app.circleci.com/pipelines/github/emscripten-core/emscripten/54289/workflows/db8f6174-b54d-4ed8-9ebd-914022760b58/jobs/1295567 :

error: 

it looks like the Rust project used to create this Wasm file was linked against
version of wasm-bindgen that uses a different bindgen format than this binary:

  rust Wasm file schema version: 0.2.128
     this binary schema version: 0.2.127 (a579ee62b)

Currently the bindgen format is unstable enough that these two schema versions
must exactly match. You can accomplish this by either updating this binary or
the wasm-bindgen dependency in the Rust project.

You should be able to update the wasm-bindgen dependency with:

    cargo update -p wasm-bindgen --precise 0.2.127 (a579ee62b)

don't forget to recompile your Wasm file! Alternatively, you can update the
binary with:

    cargo install -f wasm-bindgen-cli --version 0.2.128

if this warning fails to go away though and you're not sure what to do feel free
to open an issue at https://github.com/wasm-bindgen/wasm-bindgen/issues!

emcc: error: '/root/.cargo/bin/wasm-bindgen test_multi.wasm --keep-lld-exports --keep-debug --out-dir /tmp/emtest_l7t4steo/emscripten_temp_1tropu2u/bindgen_out' failed (returned 1)
None
None
  test_wasm_bindgen_tsd_multi_return (test_other.other) ... FAIL (0.001s)