wasm32-unknown-unknown changes broke builds that assumed less features

[nbittich]

After upgrading to the latest release, it looks like the llvm update broke my ci pipeline for the Wasm build.

The command that’s failing:

wasm-pack build --target nodejs --release --scope nbittich ./rdfa-wasm

Error message:

unexpected false: Bulk memory operations require bulk memory [--enable-bulk-memory], on ...

Here’s the GitHub Actions run where it failed:
https://github.com/nbittich/graph-rdfa-processor/actions/runs/15053071089

After some digging, I found this in the Rust docs (beta):
https://doc.rust-lang.org/beta/rustc/platform-support/wasm32-unknown-unknown.html

To fix it, I ended up making a few changes:

• Added this to Cargo.toml:

  [package.metadata.wasm-pack.profile.release] 
  wasm-opt = ["-O", "--enable-bulk-memory", "--enable-mutable-globals"]

• Also added the Rust compiler flag: -Ctarget-cpu=mvp

The commit with the fix:
nbittich/graph-rdfa-processor@f822e1e

It would be nice to mention this somewhere, maybe in the release notes, as it took me a bit to figure out what was going on. Hope this helps others who might run into the same issue.

Edit: this is rust stable (1.87.0)

[dalance]

I got the same issue.
https://github.com/veryl-lang/doc/actions/runs/15058339246/job/42328679579

In my environment, adding wasm-opt to Cargo.toml resolved the issue.
veryl-lang/doc@d1b1c0f

[dalance]

@nbittich How about changing the title to more clear like "WASM build failure on Rust 1.87.0" for people searching a workaround of this issue.

[workingjubilee]

wasm is not an acronym.

[workingjubilee]

This change was in 1.82 though? We did more than put it in release notes, we had an entire blog post specifically about it.

https://blog.rust-lang.org/2024/09/24/webassembly-targets-change-in-default-target-features/

[workingjubilee]

My understanding of things is that this is both working as intended and is not actually specific to the Rust 1.87 release as it was really part of Rust 1.82. There is no fix on our end aside from possibly more support for the wasm32v1-none target which should approximately never have this issue. I am going to close this issue, but if something was left unaddressed then please feel free to mention it, as this can be reopened.