Commits on Aug 16, 2019

1. Add support for emitting a Wasm Interface Types section …

   This commit adds support to `wasm-bindgen` to emit a WebAssembly module
   that contains a WebAssembly Interface Types section. As of today there are no
   native consumers of these WebAssembly modules, and the actual binary format
   here is basically arbitrary (chosen by the `wasm-webidl-bindings` crate). The
   intention is that we'll be following the [WebAssembly Interface
   Types proposal][proposal] very closely and update here as necessary.
   
   The main feature added in this PR is that a new experimental environment
   variable, `WASM_INTERFACE_TYPES=1`, is recognized by the `wasm-bindgen`
   CLI tool. When present the CLI tool will act differently than it does
   today:
   
   * The `anyref` feature will be implicitly enabled
   * A WebAssembly interface types section will be emitted in the
     WebAssembly module
   * For now, the WebAssembly module is strictly validated to require zero
     JS glue. This means that `wasm-bindgen` is producing a fully
     standalone WebAssembly module.
   
   The last point here is one that will change before this functionality is
   stabilized in `wasm-bindgen`. For now it reflects the major use case of
   this feature which is to produce a standalone WebAssembly module with no
   support JS glue, and to do that we need to verify properties like it's
   not using JS global names, nonstandard binding expressions, etc. The
   error messages here aren't the best but they at least fail compilation
   at some point instead of silently producing weird wasm modules.
   
   Eventually it's envisioned that a WebAssembly module will contain an
   interface types section but *also* have JS glue so binding expressions
   can be used when available but otherwise we'd still generate JS glue for
   things like nonstandard expressions and accessing JS global values.
   
   It should be noted that a major feature not implemented in
   `wasm-bindgen` yet is the multi-value proposal for WebAssembly. This is
   coming soon (as soon as we can) in `walrus` and later for a pass here,
   but for now this means that returning multiple values (like a string
   which has a pointer/length) is a bit of a hack. To enable this use case
   a `wasm-bindgen`-specific-convention which will never be stabilized is
   invented here by using binding expression to indicate "this return value
   is actually returned through an out-ptr as the first argument list".
   This is a gross hack and is guaranteed to be removed. Eventually we will
   support multi-value and the wasm module emitted will simply use
   multi-value and contain internal polyfills for Rust's ABI which returns
   values through out-ptrs.
   
   Overall this should make `wasm-bindgen` usable for playing around with
   the WebIDL bindings proposal and helping us get a taste of what it looks
   like to have entirely standalone WebAssembly modules running in multiple
   environments, no extra fluff necessary!
   
   [proposal]: https://github.com/webassembly/webidl-bindings

   

   alexcrichton committed Aug 16, 2019
   Configuration menu

   • View commit details
   • Copy full SHA for c5dd572
   • Browse repository at this point

   Copy the full SHA

   c5dd572 View commit details

   Browse the repository at this point in the history