nightly-2025-02-18 wasm-opt cannot process resulting binary

[Ddystopia]

I bisected by hand and at nightly-2025-02-18 wasm-opt started giving errors like this:

...
[wasm-validator error in function 2590] unexpected false: Bulk memory operations require bulk memory [--enable-bulk-memory], on
(memory.copy
 (local.get $0)
 (i32.add
  (local.get $4)
  (i32.const 8)
 )
 (i32.const 40)
)
[wasm-validator error in function 2621] unexpected false: Bulk memory operations require bulk memory [--enable-bulk-memory], on
(memory.copy
 (i32.add
  (local.get $2)
  (i32.shl
   (local.get $8)
   (i32.const 2)
  )
 )
 (i32.add
  (local.get $2)
  (i32.shl
   (local.get $0)
   (i32.const 2)
  )
 )
 (local.get $5)
)
...

It asks for --enable-bulk-memory, if give it to it, other errors reveal (this is the whole output):

> wasm-opt -Oz project.wasm -o new.wasm --enable-bulk-memory
[wasm-validator error in function 520] unexpected false: all used features should be allowed, on
(i32.trunc_sat_f32_s
 (f32.mul
  (local.get $13)
  (f32.const 20)
 )
)
[wasm-validator error in function 520] unexpected false: all used features should be allowed, on
(i32.trunc_sat_f32_u
 (local.tee $13
  (f32.add
   (local.get $13)
   (f32.const 60)
  )
 )
)
[wasm-validator error in function 1103] unexpected false: all used features should be allowed, on
(i32.trunc_sat_f64_u
 (local.tee $4
  (call $fimport$187
   (i32.load
    (i32.load
     (local.get $1)
    )
   )
   (i32.load offset=12
    (local.get $2)
   )
  )
 )
)
[wasm-validator error in function 1120] unexpected false: all used features should be allowed, on
(i64.trunc_sat_f64_s
 (local.get $4)
)
[wasm-validator error in function 1908] unexpected false: all used features should be allowed, on
(i64.trunc_sat_f64_u
 (local.get $9)
)
Fatal: error validating input

For wasm-opt I tried versions form 116 to 120, all failed.

I am compiling web application with dioxus, it uses wasm-bindgen.

[saethlin]

Can you share a reproducer?

I bisected by hand and at nightly-2025-02-18

Can you bisect using cargo-bisect-rustc to find the relevant PR?

[nikic]

This is due to the LLVM 20 upgrade, which enables bulk-memory and nontrapping-fptoint by default. Need to update https://doc.rust-lang.org/rustc/platform-support/wasm32-unknown-unknown.html#enabled-webassembly-features.

cc @alexcrichton

[alexcrichton]

I've sent #137322 for an update to the docs. Historically though otherwise this has generally been a "wontfix" issue in the sense that it's expected that new features will be enabled-by-default over time and downstream tooling should be expecting this.

@Ddystopia are you running wasm-opt by hand? If so it might be good to raise an issue over there to have these proposals enabled by default. If not it might be reasonable to file an issue with the tool invoking wasm-opt to pass these --enable-* flags by default.

[alexcrichton]

Oh I can also mention, the link that @nikic posted also has instructions/documentation for turning off on-by-default features if you find that helpful as well @Ddystopia

[jieyouxu]

I'm going to unmark this as a regression since it's expected that LLVM will continue to enable wasm features that become sufficiently baked.

[Ddystopia]

I will open corresponding issues. Should that issue be closed, considering that it is expected?

[jieyouxu]

I edited #137322's PR description to have that close this issue w/ the doc part once that merges.

[eric-seppanen]

A lot of downstream tools (e.g. trunk) call out to wasm-opt, and it causes a lot of downstream build breakage when new wasm features get turned on. The error messages are uninformative and it's not always obvious what the fix is.

So far the discussion here hasn't led to a clear way forward. It would be nice if wasm-opt weren't so critical to the rust-webassembly ecosystem, but in the meantime it seems like this should be called out in the release notes so people aren't surprised by the breakage.

[eric-seppanen]

It would be very helpful if someone with deep webassembly knowledge could weigh in on trunk-rs/trunk#904 .

Would any of these options be the recommended way forward? Should trunk enable all the latest things by default as soon as llvm/rustc does?

[alexcrichton]

@eric-seppanen have you reached out to the wasm-opt/binaryen folks about this? I suspect they'd be accomodating to the suggestion to enable these proposals by default to match LLVM

[eric-seppanen]

@eric-seppanen have you reached out to the wasm-opt/binaryen folks about this? I suspect they'd be accomodating to the suggestion to enable these proposals by default to match LLVM

@alexcrichton
I don't really understand what request should be made. I'm not terribly familiar with the webassembly features, and I'm not a trunk maintainer. What would it mean to say "enable these proposals by default to match LLVM"? Does that mean that each wasm-opt release has a set of defaults that matches a particular llvm version? Or that it should inspect the incoming binaries and somehow determine which set of features to enable for its output? Is this problem specific to rust, or do I need to understand how other languages handle this issue?

[alexcrichton]

I'd recommend making a request that the default set of enabled features in binaryen either be (a) proposals that are stage 4+ or (b) proposals that are on-by-default in LLVM. In wasmtime/wasm-tools we do (a) and find that it works well for our use cases, but binaryen might have other use cases as well.

In my mind if binaryen has good reason for not enabling a feature by default then that should be a factor in a decision to enable something in LLVM by default. Often though I find that things aren't on-by-default because it's just forgotten about.