feat(compiler): Deduplicate foreign imports

[spotandjake]

This enables the binaryen pass to de-duplicate imports, if were against using the binaryen pass I think we can also do this manually in compcore and just filter through the imports in compile_imports but we'll have to manually handle re-patching the import identifiers through the program.

This makes developing for runtimes such as wasmtime a little nicer.

This also adds the assertWasmSnapshot which let's us test wat snapshots for optimizations that occur after, as the regular mashtree snapshots won't catch these, we can get away with a simple print("test") here because multiple places in the runtime import fd_write.

Closes: #2152

[ospencer]

I think that you're getting a stack overflow because the snapshot is massive. As of the new object files PR, we don't do snapshots of wat anymore because they're a lot bigger (and thus impossible to really diff/read). The way to test this is programmatically. An example of a test that looks at wasm exports (and you can do the same for imports) is

grain/compiler/test/suites/modules.re

Line 156 in 4b56c53

expect.list(Option.get(export_sections)).toContainEqual((

.

[ospencer]

I would lean towards trying to prevent the issue rather than rely on the Binaryen pass. I think you're right that this would be annoying to resolve during codegen, but I don't think this is bad to fix as a part of linking at all, because it's already keeping track of names to rewrite. You could dedupe the imports and just keep the needed name in the resolver.

[spotandjake]

I refactored this change to handle things in compcore but I still need to figure out why our smallest program got larger, it seems to be that the wrapper isn't being inlined anymore but I am unsure why.

[spotandjake]

Both those changes have been made.

[ospencer]

Why is this marked as breaking?

[spotandjake]

Why is this marked as breaking?

I wasn't sure if we considered this optimization a breaking change or not, I'll mark it as non breaking though.

[spotandjake]

As a note if we merge this before a fix is made for #2243 we will need to make sure to handle the foreign_import_resolutions logic for globals as well.