Commit Graph

12 Commits

Author SHA1 Message Date
Nick Fitzgerald
a0582cd6f2 rustfmt the publish script 2019-09-16 12:54:05 -07:00
Nick Fitzgerald
d9c4164c11 Also publish the wasm-bindgen-wasm-conventions crate 2019-09-16 12:54:05 -07:00
Nick Fitzgerald
44c3f8ad2d Introduce the multi-value-xform crate
This crate provides a transformation to turn exported functions that use a
return pointer into exported functions that use multi-value.

Consider the following function:

```rust
pub extern "C" fn pair(a: u32, b: u32) -> [u32; 2] {
    [a, b]
}
```

LLVM will by default compile this down into the following Wasm:

```wasm
(func $pair (param i32 i32 i32)
  local.get 0
  local.get 2
  i32.store offset=4
  local.get 0
  local.get 1
  i32.store)
```

What's happening here is that the function is not directly returning the
pair at all, but instead the first `i32` parameter is a pointer to some
scratch space, and the return value is written into the scratch space. LLVM
does this because it doesn't yet have support for multi-value Wasm, and so
it only knows how to return a single value at a time.

Ideally, with multi-value, what we would like instead is this:

```wasm
(func $pair (param i32 i32) (result i32 i32)
  local.get 0
  local.get 1)
```

However, that's not what this transformation does at the moment. This
transformation is a little simpler than mutating existing functions to
produce a multi-value result, instead it introduces new functions that wrap
the original function and translate the return pointer to multi-value
results in this wrapper function.

With our running example, we end up with this:

```wasm
;; The original function.
(func $pair (param i32 i32 i32)
  local.get 0
  local.get 2
  i32.store offset=4
  local.get 0
  local.get 1
  i32.store)

(func $pairWrapper (param i32 i32) (result i32 i32)
  ;; Our return pointer that points to the scratch space we are allocating
  ;; on the shadow stack for calling `$pair`.
  (local i32)

  ;; Allocate space on the shadow stack for the result.
  global.get $shadowStackPointer
  i32.const 8
  i32.sub
  local.tee 2
  global.set $shadowStackPointer

  ;; Call `$pair` with our allocated shadow stack space for its results.
  local.get 2
  local.get 0
  local.get 1
  call $pair

  ;; Copy the return values from the shadow stack to the wasm stack.
  local.get 2
  i32.load
  local.get 2 offset=4
  i32.load

  ;; Finally, restore the shadow stack pointer.
  local.get 2
  i32.const 8
  i32.add
  global.set $shadowStackPointer)
```

This `$pairWrapper` function is what we actually end up exporting instead of
`$pair`.
2019-09-10 17:32:30 -07:00
Alex Crichton
228f58dca3 Bump to 0.2.39 2019-03-13 11:02:27 -07:00
Alex Crichton
4181fb311a Add experimental support for the anyref type
This commit adds experimental support to `wasm-bindgen` to emit and
leverage the `anyref` native wasm type. This native type is still in a
proposal status (the reference-types proposal). The intention of
`anyref` is to be able to directly hold JS values in wasm and pass the
to imported functions, namely to empower eventual host bindings (now
renamed WebIDL bindings) integration where we can skip JS shims
altogether for many imports.

This commit doesn't actually affect wasm-bindgen's behavior at all
as-is, but rather this support requires an opt-in env var to be
configured. Once the support is stable in browsers it's intended that
this will add a CLI switch for turning on this support, eventually
defaulting it to `true` in the far future.

The basic strategy here is to take the `stack` and `slab` globals in the
generated JS glue and move them into wasm using a table. This new table
in wasm is managed at the fringes via injected shims. At
`wasm-bindgen`-time the CLI will rewrite exports and imports with shims
that actually use `anyref` if needed, performing loads/stores inside the
wasm module instead of externally in the wasm module.

This should provide a boost over what we have today, but it's not a
fantastic strategy long term. We have a more grand vision for `anyref`
being a first-class type in the language, but that's on a much longer
horizon and this is currently thought to be the best we can do in terms
of integration in the near future.

The stack/heap JS tables are combined into one wasm table. The stack
starts at the end of the table and grows down with a stack pointer (also
injected). The heap starts at the end and grows up (state managed in
linear memory). The anyref transformation here will hook up various
intrinsics in wasm-bindgen to the runtime functionality if the anyref
supoprt is enabled.

The main tricky treatment here was applied to closures, where we need JS
to use a different function pointer than the one Rust gives it to use a
JS function pointer empowered with anyref. This works by switching up a
bit how descriptors work, embedding the shims to call inside descriptors
rather than communicated at runtime. This means that we're accessing
constant values in the generated JS and we can just update the constant
value accessed.
2019-02-20 07:28:54 -08:00
Nick Fitzgerald
51989aed88 No more wasm-bindgen-gc crate, so we don't need to publish it! 2019-02-12 12:44:45 -08:00
Alex Crichton
56400c3738 Don't use path dependencies in examples
This commit updates all examples to not use `path` dependencies but
rather use versioned dependencies like would typically be found in the
wild. This should hopefully make the examples more copy-pastable and
less alien to onlookers!

The development of the examples remains the same where they continue to
use the `wasm-bindgen`, `js-sys`, `web-sys`, etc from in-tree. The
workspace-level `[patch]` section ensures that they use the in-tree
versions instead of the crates.io versions.
2018-11-07 11:27:43 -08:00
Alex Crichton
bb28f76906 Try to improve the publish script 2018-10-29 13:08:22 -07:00
Alex Crichton
7fad2bf0c8 Bump to 0.2.26 2018-10-29 12:56:37 -07:00
Nick Fitzgerald
dd82a3e134 Bump to 0.2.25 2018-10-10 13:19:40 -07:00
Nick Fitzgerald
f834a427d7 Bump to version 0.2.23 (and js-sys and wasm-bindgen-futures to 0.3.0) 2018-09-26 07:31:54 -07:00
Alex Crichton
98008b9e77 Bump to 0.2.18
At the same time, also add a `publish.rs` script to ease our publishing woes.
2018-08-27 13:37:55 -07:00