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.

[dalance]

According to https://doc.rust-lang.org/beta/rustc/platform-support/wasm32-unknown-unknown.html#enabled-webassembly-features, bulk-memory feature was enabled at Rust 1.87, and it seems to be a cause of this issue.
So I think this issue is specific to Rust 1.87.

The issue likely stems from wasm-pack not properly handling Rust enabling new features. The following issue might be related.

rustwasm/wasm-pack#1441

Therefore, it’s reasonable to say there’s nothing Rust can do about it. However, given the trust in Rust’s stability (regressions rarely occur with stable updates), it’s disappointing that simply updating Rust causes the build to break.

[workingjubilee]

Our stability promises extend to what we can best control. The relevant RFCs such as api-evolution and language-semver explain what they cover, and the behavior of specific platforms is not really included, whereas type signatures of std functions are.

wasm has decided it wants to be a moving target of a platform. When it comes to something like a target definition, it is often not very helpful if rustc puts its foot down but clang does not. We can differ on target defs but we would prefer not to, to say the least. So it is best to pursue this with e.g. the WebAssembly/tool-conventions repo, where you will find issues such as

• Enabling features by default in LLVM WebAssembly/tool-conventions#158

[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/

Also yes, you're right that the bulk memory change was in 1.87, I got slightly confused by the --enable-mutable-globals flag being involved for some reason. (I actually think that was quite a while ago...)

[dalance]

Also yes, you're right that the bulk memory change was in 1.87, I got slightly confused by the --enable-mutable-globals flag being involved for some reason. (I actually think that was quite a while ago...)

After subsequent investigation, I found that --enable-mutable-globals is not necessary to resolve this issue, only --enable-bulk-memory is sufficient.