Skip to content

fix(wasm64): fix tier-3 target handling and bump binaryen to v129#1586

Merged
guybedford merged 1 commit into
wasm-bindgen:masterfrom
guybedford:fix/wasm64-binaryen-version
May 22, 2026
Merged

fix(wasm64): fix tier-3 target handling and bump binaryen to v129#1586
guybedford merged 1 commit into
wasm-bindgen:masterfrom
guybedford:fix/wasm64-binaryen-version

Conversation

@guybedford

@guybedford guybedford commented May 22, 2026

Copy link
Copy Markdown
Contributor

Resolves #1576.

Building for wasm64-unknown-unknown was broken in two ways introduced by #1553:

  1. rustup target add wasm64-unknown-unknown failed because wasm64 is a tier-3 target with no prebuilt artifacts. The user had to work around this with --mode force.
  2. The bundled wasm-opt (binaryen v117) could not parse 64-bit tables; support landed in binaryen v118.

The cargo target triple — declared in .cargo/config.toml, CARGO_BUILD_TARGET, or as an extra cargo argument (-- --target wasm64-unknown-unknown) — is the source of truth for what wasm-pack builds. The target triple resolver now follows the same precedence cargo uses (CLI > env > .cargo/config.toml walk-up > $CARGO_HOME/config.toml > default), so wasm-pack and cargo always agree on the target.

For tier-3 wasm targets (currently the wasm64-* family) wasm-pack stays out of the cargo invocation — it does not inject +nightly or -Z build-std. Those would override a project's rust-toolchain.toml pin or surprise users who hadn't intended a nightly build. Cargo-native config is the right place for those choices:

# rust-toolchain.toml
[toolchain]
channel = "nightly"
components = ["rust-src"]
# .cargo/config.toml
[build]
target = "wasm64-unknown-unknown"

[unstable]
build-std = ["std", "panic_abort"]

With that in place, wasm-pack build Just Works. wasm-pack's role for tier-3 wasm:

  • verifies the active toolchain is nightly, with a helpful error pointing at the config above if it isn't,
  • installs the rust-src component for the active toolchain via rustup if missing,
  • skips the rustup target add attempt (which always fails for tier-3 targets),
  • passes --enable-memory64 to wasm-opt so the optimiser accepts 64-bit memories and tables.

The bundled binaryen is bumped from version_117 to version_129 (latest stable) so wasm-opt accepts 64-bit memories and tables. The --enable-memory64 flag was already being passed for wasm64 builds, but the bundled binary was too old to honour it.

--panic-unwind is untouched: it remains a flag-driven recipe that injects +nightly and the corresponding -Z build-std=std,panic_unwind + RUSTFLAGS=-Cpanic=unwind.

Tests:

  • New unit test build::tests::tier3_wasm_detection covers the triple-classification helper.
  • New command::build::tests unit tests cover the cargo-config walk-up resolution (workspace root, crate-over-workspace precedence, missing-config-returns-none).
  • New wasm_opt_prebuilt_url_is_pinned_version test guards against regressing the binaryen version below v118 (the first release with 64-bit table support).
  • Existing all_latest_tool_download_urls_valid validates the v129 release URLs across all supported architectures.

@guybedford guybedford force-pushed the fix/wasm64-binaryen-version branch 3 times, most recently from 448cc8a to 620a42a Compare May 22, 2026 22:54
@guybedford guybedford changed the title fix(wasm64): drive nightly + build-std and bump binaryen to v129 fix(wasm64): heal toolchain and bump binaryen to v129 May 22, 2026
Resolves wasm-bindgen#1576.

Building for wasm64-unknown-unknown failed in two ways introduced by
wasm-bindgen#1553:

1. `rustup target add wasm64-unknown-unknown` failed because wasm64 is
   a tier-3 target with no prebuilt artifacts. Users had to work around
   this with `--mode force`.
2. The bundled wasm-opt (binaryen v117) could not parse 64-bit tables;
   support landed in binaryen v118.

The cargo target triple — declared in `.cargo/config.toml`,
`CARGO_BUILD_TARGET`, or as an extra cargo argument
(`-- --target wasm64-unknown-unknown`) — is the source of truth for
what wasm-pack builds. The target triple resolver now follows the same
precedence cargo uses (CLI > env > `.cargo/config.toml` walk-up >
`$CARGO_HOME/config.toml` > default), so wasm-pack and cargo always
agree on the target.

For tier-3 wasm targets (currently the `wasm64-*` family) wasm-pack
stays out of the cargo invocation — it does not inject `+nightly` or
`-Z build-std` (those would override a project's `rust-toolchain.toml`
pin or surprise users who hadn't intended a nightly build). Instead it:

* verifies the active toolchain is nightly, with a helpful error
  pointing at `rust-toolchain.toml` and `[unstable] build-std` in
  `.cargo/config.toml` if it isn't,
* installs the `rust-src` component for the active toolchain via
  rustup if missing,
* skips the `rustup target add` attempt (which always fails for tier-3
  targets),
* passes `--enable-memory64` to wasm-opt so the optimiser accepts
  64-bit memories and tables.

The bundled binaryen is bumped from `version_117` to `version_129`
(latest stable) so wasm-opt accepts 64-bit memories and tables.

`--panic-unwind` is untouched.

Tests:

* New unit test `build::tests::tier3_wasm_detection` covers the
  triple-classification helper.
* New `command::build::tests` unit tests cover the cargo-config
  walk-up resolution.
* New `wasm_opt_prebuilt_url_is_pinned_version` test guards against
  regressing the binaryen version below v118 (the first release with
  64-bit table support).
* Existing `all_latest_tool_download_urls_valid` validates the v129
  release URLs across all supported architectures.
@guybedford guybedford force-pushed the fix/wasm64-binaryen-version branch from 620a42a to 7751547 Compare May 22, 2026 22:57
@guybedford guybedford changed the title fix(wasm64): heal toolchain and bump binaryen to v129 fix(wasm64): fix tier-3 target handling and bump binaryen to v129 May 22, 2026
@guybedford guybedford merged commit 1d35e8f into wasm-bindgen:master May 22, 2026
4 checks passed
@guybedford guybedford deleted the fix/wasm64-binaryen-version branch May 22, 2026 23:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Issues when compiling to wasm64-unknown-unknown w/o --mode force and w/ optimisations

1 participant