Reintroduce wasm-merge

[kripken]

We used to have a wasm-merge tool but removed it for a lack of use cases. Recently
use cases have been showing up in the wasm GC space and elsewhere, as people are
using more diverse toolchains together, for example a project might build some C++
code alongside some wasm GC code. Merging those wasm files together can allow
for nice optimizations like inlining and better DCE etc., so it makes sense to have a
tool for merging.

Removal: #1969

Requests:

• wasm-merge - why it has been deleted #2174
• Compiling and linking wat files #2276
• wasm-link? #2767

This PR is a compete rewrite of wasm-merge, not a restoration of the original
codebase. The original code was quite messy (my fault), and also, since then
we've added multi-memory and multi-table which makes things a lot simpler.

The linking semantics are as described in the "wasm-link" issue #2767 : all we do
is merge normal wasm files together and connect imports and export. That is, we
have a graph of modules and their names, and each import to a module name can
be resolved to that module. Basically, like a JS bundler would do for JS, or, in other
words, we do the same operations as JS code would do to glue wasm modules
together at runtime, but at compile time. See the README update in this PR for a
concrete example.

There are no plans to do more than that simple bundling, so this should not
really overlap with wasm-ld's use cases.

This should be fairly fast as it works in linear time on the total input code. However,
it won't be as fast as wasm-ld, of course, as it does build Binaryen IR for each
module. An advantage to working on Binaryen IR is we could optimize right after
merging, but in this first version no optimizations are done yet.

Perhaps this new tool should be given a new name, to differentiate it from the
old wasm-merge? Other name options might be wasm-link or wasm-bundle
perhaps.

[kripken]

For the CLI UI for naming modules, I propose that the optional flag --name=foo means the next given input file will be assigned name "foo". Otherwise, if the next given input file has a module name (in the text or in the name section), then that name should be used. Otherwise, the base filename (without extension) of the input file should be used as the module name.

The one maybe odd part there is the mixture of positional and non-positional items. Making one depend on the other is not something I'm familiar with in commandline tools. Or is there precedent?

[kripken]

Another option for the commandline UI might be to forgo positional arguments entirely, as they are potentially confusing when mixed with others. We could have this:

wasm-merge --input=a.wasm --name=foo --input=b.wasm --name=bar --output=merged.wasm

Basically we could have --input/-i for inputs like we have --output/-o for the output.

[tlively]

One similar use of --flags to affect positional arguments is the --whole-archive and --no-whole-archive linker flags.

[tlively]

Code and tests LGTM. I believe the only remaining questions are 1) the CLI UI for naming modules, and 2) what options to provide and what to do by default for conflicting export names.

[kripken]

One similar use of --flags to affect positional arguments is the --whole-archive and --no-whole-archive linker flags.

Very good point... I guess there is precedent for such stuff.

I don't really have a strong feeling of what's best for the CLI UI. Perhaps we can bikeshed this on the Monday meeting if there's time.

For handling of export conflicts, do you agree we should have 3 modes like I was getting at before?

1. Rename to avoid conflicts. (Helps if the user knows and expects conflicts, e.g. a main in each module.)
2. Error on conflicts. (Avoids surprises.)
3. Avoid conflicts by keeping the exports of exactly one module. (Best for the main module + side modules use case.)

If so perhaps 2 should be the default, as the least surprising, as you've been suggesting?

[tlively]

For handling of export conflicts, do you agree we should have 3 modes like I was getting at before?

Yes! Sounds good.

If so perhaps 2 should be the default, as the least surprising, as you've been suggesting?

That sounds great to me.

[kripken]

Ok, 3 modes + new default are now implemented.

[tlively]

In general I think it would be more useful for this third mode to collect all the exports and use module order only to resolve conflicts. That would still expose any non-conflicting exports from later modules. The reason this is more useful is that exporting more things than the embedder expects does not cause linkage failures, so this would cover both the use cases covered by KeepOnlyFirstModuleExports as well as use cases that need the other exports to be exposed as well.

[tlively]

Sorry I didn't catch this earlier when you were describing the 3 modes you had in mind!

[kripken]

Interesting. That would allow more things to work. But it would also add more effort for the user in the common case this is meant to address, which is a main module + side modules, since we never want the side module's exports to remain. But maybe that's just more work we should expect the user to do, hmm... they also likely would want to prune some main module exports.

[kripken]

After more thought this does seem better. Changed to that.

[tlively]

LGTM 🎉 🎉 🎉