saw this same issue the other day in some e2e tests

For me this issue showed up in CI. The last build that was correct before the failed one today was on July 21st. The nightly compiler from that version already exhibited the bug so it seems the cause is some dependency somewhere triggering this behavior which is not supported by wasm-opt, but I haven't been able to trace which one yet.

Thanks for the input @EverlastingBugstopper, @vtavernier.

I've created a bit more atomic example:

// src/lib.rs
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub struct Boat {
    length: u32,
}

#[wasm_bindgen]
impl Boat {
    // works
    pub fn new(length: u32) -> Self {
        Self { length }
    }

    // doesn't work
    pub fn float(&self) -> String {
        String::from("floating... ⛵")
    }

    // works
    pub fn volume(&self) -> u32 {
        self.length * 2
    }
}

// doesn't work
#[wasm_bindgen]
pub fn string() -> String {
    String::from("wasm-opt")
}

So it seems returning a String fails wasm-opt.

It is also failing, when returning some structs, but for others not. I will investigate what the failing ones have in common.

For me the bug was introduced by wasm-bindgen 0.2.66 (0.2.65 is fine).

The problem seems to be with the non-MVP webassembly feature mutable-global. Adding --enable-mutable-globals to the wasm-opt command seems to fix it (see WebAssembly/binaryen#3006 (comment)).

My workaround is now:

1. disable wasm-opt in your Cargo.toml ...

[package.metadata.wasm-pack.profile.release]
wasm-opt = false

2. ... run wasm-pack ...

$ wasm-pack build

3. ... and optimize manually

$ /path/to/wasm-opt pkg/repo_bg.wasm -o pkg/repo_bg.wasm -O --enable-mutable-globals

(My /path/to/wasm-opt is ~/.cache/.wasm-pack/wasm-opt-4d7a65327e9363b7/wasm-opt.)

Edit: Originally I recommended to use wasm-opt [...] -O -all, but this creates new errors.

Ran into the same issue while doing the wasm game of life tutorial: https://rustwasm.github.io/docs/book/game-of-life/implementing.html

@Urhengulas It's possible to specify wasm-opt arguments, so you should be able to do this:

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

Change -Oz to whatever optimization level you need.

@Urhengulas It's possible to specify wasm-opt arguments, so you should be able to do this:

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

Change -Oz to whatever optimization level you need.

Thanks @0xd4d. This surely is the better workaround.

Mutable globals are now phase 4 in the WebAssembly CG, it should be enabled by default in wasm-opt

@xtuc I don't think we have a clear answer on that. Discussions have been going on about what the defaults should be for various tools including wasm-opt and LLVM and we should discuss those more on https://github.com/WebAssembly/tool-conventions cc @sbc100

The main risk I see is that we turn a feature on by default, but not all VMs support it yet, and if the developer doesn't test everywhere then they can end up shipping code that only works in some places.

In this particular case I think we wasm-opt should be driven by the target-features section of the input file. So perhaps the problem is that llvm/wasm-ld doesn't know to add mutable-globals to the target-features of the output binary.

While I agree that using/adding new features during wasm-opt would be bad, I don't think limiting the input feature set is something wasm-opt should be doing. If my upstream toolchain is choosing to emit mutable-globals wasm-opt should honor that. The job of wasm-opt is not to limit features in its input, right?

My understanding of the target-features section is that it's used by the toolchain but doesn't necessarily reflect what the target browser supports. In JS we used to transpile down the unsupported features given some user preference.

target-features is used by the toolchain to specific the feature set that the output is expecting. If llvm's output includes the use of given feature that feature should appear in the target-features section. If it doesn't, that is a bug IIUC.

If you want to transpile those features away in order to support older runtimes that seems fine too.

In this case it seems clear that this is the problem: llvm is producing code that depends a feature but that information not being correctly transmitted to wasm-opt.

I don't have much context here on what exactly the problem is but I will say that whatever changed broke pretty much every standard Hello World project in the Rust-Wasm ecosystem and that doesn't feel great. Wherever this change was introduced needs to have some sort of integration test with some common tutorials so that releases don't break documentation across the entire ecosystem.

If a breaking change must happen (which I'd argue it probably doesn't) then there should be advance notice, some warning messages in terminal output before a breaking change (similar to how Rust itself deprecates things), and work put in to update documentation across the ecosystem that does not break with default settings.

edit: i think we might want to revisit whether wasm-pack should even run wasm-opt by default instead of having it be opt in until it has stabilized - these breaking changes are not fun to work with.

For me this ends up slightly more problematic - due to React Native support, I'm also compiling from the generated wasm to asm.js (same binaryen toolset, different binary), and cannot find a working option to make that work at all. (So -all works for wasm-opt and does seem to work on wasm2js, however the output fails all tests)

There is def. a mismatch with this tooling and the binaryen tooling that has "some" impacts.

TL;DR Can (based on suggestions here) get the wasm part compiled, bundled and optimized, however have no luck generating output to an asm.js bundle from the compiled WASM now being generated. For now fixed to the last know working .25 and all is well.

@EverlastingBugstopper: i think we might want to revisit whether wasm-pack should even run wasm-opt by default instead of having it be opt in until it has stabilized - these breaking changes are not fun to work with.

I agree. Maybe mirroring the cargo build behaviour would be an option. This is wasm-pack build builds in debug mode [what --dev currently does ([optimized debuginfo], no wasm-opt)] and wasm-pack build --release builds the optimized wasm and also optimizes with wasm-opt (like it currently already does).

@Niedzwiedzw currently my solution is to use a fork of wasm-pack, as it's not maintained now. Or you could directly use wasm-bindgen-cli to completely remove wasm-pack dependency.

This issue may be fixed by rustwasm/wasm-bindgen#2391 , which prevents wasm-bindgen from exporting mutable globals for compatibility reasons.

rustwasm/wasm-bindgen#2391 has been merged & released in wasm-bindgen 0.2.70. I believe this fixes the issue, and this ticket can now be closed.

Is this fixed? I just ran into it trying to compile the threads example: https://rustwasm.github.io/docs/wasm-bindgen/examples/raytrace.html