[wasm-merge] Does not print to stdout if -o is not specified

[surma]

I finally have a use-case for wasm-merge and trying to use it made me think the tool was broken! (It is not).

It says:

wasm-merge options:
-------------------

  --output,-o                          Output file (stdout if not specified)

However, if you don’t specify -o nothing gets printed. -o - makes it print to stdout as expected. I suspect the default value for this flag is not implemented?

[kripken]

Thanks @surma ! Looks like the help text was indeed wrong, fix in #7398

[kripken]

I'd also be curious what your use case for wasm-merge is, if you can share that...

[surma]

PR

Thanks for landing the PR so quickly. Appreciate that! Just one quick note: I think after this PR, you will still see no output. Would it be worth to either make the flag mandatory or emit a warning when no output is specified?

Use-Case

I am compiling a piece of Rust code to wasm and using jco to generate the JS code to load it on the web (that is actually a really nice DX and feels like the spiritual successor to wasm-bindgen, as in a generic, properly source-language-agnostic way to generate JS bindings for a Wasm module).

However, I am also depending on a C library, which somewhat forces me to target wasm32-wasip2 which means the resulting WebAssembly module has a lot of imports from WASI preview 2, even though my core functionality does not rely on them at all. jco does handle those using the BCA’s preview2 shim, but that’s a significant amount of bytes for code paths that are never really taken, just because libc is in the build.

My goal here is to “terminate” Wasi at build time.

There is wasi-virt, which generates a Wasm module with a virtual implementation of WASI. When combined with wac, that let’s me satisfy the WASI imports at the component level during build time, prevent jco from loading the shim. However, this approach didn’t really reduce the total number of bytes and resulted in a new component with a disproportionate number of new trampoline modules, which is not really acceptable for this use-case where loading performance is important.

The solution I am exploring is to terminate WASI at the core wasm level, rather than at the component level.

I am auto-generating modules for all WASI imports contained in the module, and each function just uses the unreachable instruction. I then use wasm-merge to short-circuit these imports at the Core Wasm level, and re-assemble the component afterwards. This has yielded a significantly smaller module/component and no need for the preview2 shim.

[kripken]

Interesting use case!

this approach didn’t really reduce the total number of bytes and resulted in a new component with a disproportionate number of new trampoline modules

Is there no tool that can optimize component graphs, or lower a component into a "flat" one?

Btw, if you are mixing C/C++ and Rust and targeting the web, you may be interested in https://github.com/walkingeyerobot/cxx-rust-demo (more details in emscripten-core/emscripten#23493 and other links there, but it is all wip). Though that is focused more on "C++, adding Rust" and it sounds like you are more "Rust, adding C".

Would it be worth to either make the flag mandatory or emit a warning when no output is specified?

Possibly a warning or error makes sense, yeah. I believe we have one on wasm-opt but not elsewhere. I opened #7408 to discuss.