WebAssembly / binaryen

Optimizer and compiler/toolchain library for WebAssembly
Apache License 2.0
7.52k stars 745 forks source link

Wasm vs Wasm2js export naming is incompatible #2310

Open dcodeIO opened 5 years ago

dcodeIO commented 5 years ago

With Wasm2js generating valid ES modules, some information about export names is lost making Wasm modules and their Wasm2js counterpart non-interchangeable.

For example, if the Wasm module exports a function named hello#world, this will be exported as-is in Wasm but as hello_world in Wasm2js output.

Now one could argue that the mangling is necessary to make ES modules in the first place, and another person could argue that compatibility of the resulting module instance is more important. I'd personally favor the latter, since AssemblyScript uses export names (which do allow such symbols by the spec) to transport information about what is an instance method as part of the export's name (like MyClass#myInstanceMethod vs MyClass.myStaticMethod).

Any thoughts?

kripken commented 5 years ago

I don't know much about the second option - how would that work? Something like the exports would be named by strings, instead of JS vars?

That sounds good in general to me, I didn't know that it was possible to use string names for all the imports and exports that we need here.

dcodeIO commented 5 years ago

To me it seems that ES module exports, which must be valid JS identifiers, and Wasm module exports, which allow additional characters, is generally incompatible, instead requiring exporting some sort of object that one can set arbitrary properties on. That is, if I'm not missing something.

I also wonder how this is supposed to interop with JS in the first place, since if the module has a hello#world export, one can't do import { hello#world } from "./my.wasm" anyway?

kripken commented 5 years ago

I'm not sure..

@alexcrichton I think you made the change to ES6 module output here, perhaps you had a plan for this stuff?

alexcrichton commented 5 years ago

I didn't personally consider this use case when originally porting wasm2js, but I'd recommend following whatever the ES integration spec for wasm says in this regard. It might be more reasonable for wasm2js to generate an error rather than apply its own mangling scheme, but otherwise I'm not sure how wasm2js would handle this.