fix(wasm64): fix tier-3 target handling and bump binaryen to v129#1586
Merged
guybedford merged 1 commit intoMay 22, 2026
Merged
Conversation
448cc8a to
620a42a
Compare
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.
620a42a to
7751547
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #1576.
Building for
wasm64-unknown-unknownwas broken in two ways introduced by #1553:rustup target add wasm64-unknown-unknownfailed because wasm64 is a tier-3 target with no prebuilt artifacts. The user had to work around this with--mode force.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.tomlwalk-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+nightlyor-Z build-std. Those would override a project'srust-toolchain.tomlpin or surprise users who hadn't intended a nightly build. Cargo-native config is the right place for those choices:With that in place,
wasm-pack buildJust Works. wasm-pack's role for tier-3 wasm:rust-srccomponent for the active toolchain via rustup if missing,rustup target addattempt (which always fails for tier-3 targets),--enable-memory64to wasm-opt so the optimiser accepts 64-bit memories and tables.The bundled binaryen is bumped from
version_117toversion_129(latest stable) so wasm-opt accepts 64-bit memories and tables. The--enable-memory64flag was already being passed for wasm64 builds, but the bundled binary was too old to honour it.--panic-unwindis untouched: it remains a flag-driven recipe that injects+nightlyand the corresponding-Z build-std=std,panic_unwind+RUSTFLAGS=-Cpanic=unwind.Tests:
build::tests::tier3_wasm_detectioncovers the triple-classification helper.command::build::testsunit tests cover the cargo-config walk-up resolution (workspace root, crate-over-workspace precedence, missing-config-returns-none).wasm_opt_prebuilt_url_is_pinned_versiontest guards against regressing the binaryen version below v118 (the first release with 64-bit table support).all_latest_tool_download_urls_validvalidates the v129 release URLs across all supported architectures.