Add support as a vanilla polyfill of WebIDL bindings #1690
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit adds support to `wasm-bindgen` to be a drop-in polyfill for the WebIDL bindings proposal. Lots of internal refactoring has happened previously to `wasm-bindgen` to make this possible, so this actually ends up being a very small PR! Most of `wasm-bindgen` is geared towards Rust-specific types and Rust-specific support, but with the advent of WebIDL bindings this is a standard way for a WebAssembly module to communicate its intended interface in terms of higher level types. This PR allows `wasm-bindgen` to be a polyfill for any WebAssembly module that has a valid WebIDL bindings section, regardless of its producer. A standard WebIDL bindings section is recognized in any input wasm module and that is slurped up into wasm-bindgen's own internal data structures to get processed in the same way that all Rust imports/exports are already processed. The workflow for `wasm-bindgen` looks the same way that it does in Rust today. You'd execute `wasm-bindgen path/to/foo.wasm --out-dir .` which would output a new wasm file and a JS shim with the desired interface, and the new wasm file would be suitable for loading in MVP implementations of WebAssembly. Note that this isn't super thoroughly tested, so there's likely still some lingering assumptions that `wasm-bindgen` makes (such as `__wbindgen_malloc` and others) which will need to be patched in the future, but the intention of this commit is to start us down a road of becoming a drop-in polyfill for WebIDL bindings, regardless of the source. Also note that there's not actually any producer (AFAIK) of a WebIDL bindings custom section, so it'd be that much harder to write tests to do so!
|
cc @jgravelle-google I'm curious to get your take on this as well, especially how this relates to https://github.com/jgravelle-google/wasm-webidl-polyfill. In theory wasm-bindgen itself could be compiled to wasm/JS (even using |
fitzgen
approved these changes
Aug 1, 2019
| .exports | ||
| .iter() | ||
| .find(|e| match e.item { | ||
| walrus::ExportItem::Function(f) => f == bind.func, |
There was a problem hiding this comment.
Wait -- we don't have a better way than iterating over all exports? Filed rustwasm/walrus#113
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit adds support to
wasm-bindgento be a drop-in polyfill forthe WebIDL bindings proposal. Lots of internal refactoring has happened
previously to
wasm-bindgento make this possible, so this actuallyends up being a very small PR!
Most of
wasm-bindgenis geared towards Rust-specific types andRust-specific support, but with the advent of WebIDL bindings this is a
standard way for a WebAssembly module to communicate its intended
interface in terms of higher level types. This PR allows
wasm-bindgento be a polyfill for any WebAssembly module that has a valid WebIDL
bindings section, regardless of its producer. A standard WebIDL bindings
section is recognized in any input wasm module and that is slurped up
into wasm-bindgen's own internal data structures to get processed in the
same way that all Rust imports/exports are already processed.
The workflow for
wasm-bindgenlooks the same way that it does in Rusttoday. You'd execute
wasm-bindgen path/to/foo.wasm --out-dir .whichwould output a new wasm file and a JS shim with the desired interface,
and the new wasm file would be suitable for loading in MVP
implementations of WebAssembly.
Note that this isn't super thoroughly tested, so there's likely still
some lingering assumptions that
wasm-bindgenmakes (such as__wbindgen_mallocand others) which will need to be patched in thefuture, but the intention of this commit is to start us down a road of
becoming a drop-in polyfill for WebIDL bindings, regardless of the
source. Also note that there's not actually any producer (AFAIK) of a
WebIDL bindings custom section, so it'd be that much harder to write
tests to do so!