Closed Hywan closed 5 years ago
I'm not sure what the problem is supposed to be.
WebAssembly in general isn't supposed to be hand-written, so developers using WebIDL bindings would rely on tools like wasm-bindgen
to generate the bindings.
Yeah, the func-binding statements aren't meant to be written by hand separately from a wasm module. It's possible to do so, in the same way that it's possible to write wasm itself by hand, but hand-written wasm isn't desirable for much the same reasons. Instead I would expect the bindings declarations to be generated as part of the compilation process, so they would update from one compilation to another themselves anyway.
Closing as out-of-date: the proposal has evolved and no longer involves Web IDL bindings.
Agree.
When writing Web IDL by hand, at some point, a program author should use
func-binding
which has the following form:When encoding the Web IDL definitions into a Wasm module (into a custom section), the
$<function-wasmtype-type>
is likely to be an indeterminate index, rather than a fully-qualified name. Let me explain.I see two main scenarios when having a Wasm module with Web IDL bindings:
In scenario 1, the compiler is able to resolve all the names. There is no issue.
In scenario 2, the compiler swaps the function names by indexes, and also swaps the type names by indexes. Depending on the compiler, a “debug name custom section" can be generated (c.f.
wat2wasm --debug-names
), but (i) the custom section format isn't standardized, (ii) it contains only a mapping from function indexes to function names. In all cases, a mapping from type indexes to type names is missing.So when writing
func-binding $<name> import $<function-wasm-type> …
, the program author has to use an index for$<function-wasm-type>
. This index can change from one compilation to another, which makes hand-written Web IDL hardly maintainable. After each new compilation, the program author has to ensure that its type indexes haven't moved.Am I missing something? If no, this is a problem to solve :-). One way to solve that is to introduce a new “debug type names custom section” that is basically a mapping from type indexes to type names, so that the Web IDL encoder can resolve all type names (and also function names) more easily.