2017-12-14 19:31:01 -08:00
|
|
|
[package]
|
|
|
|
name = "wasm-bindgen-cli-support"
|
2019-08-19 04:21:27 -07:00
|
|
|
version = "0.2.50"
|
2018-07-19 14:57:04 -05:00
|
|
|
authors = ["The wasm-bindgen Developers"]
|
2018-03-05 20:24:35 -08:00
|
|
|
license = "MIT/Apache-2.0"
|
2018-07-19 14:57:04 -05:00
|
|
|
repository = "https://github.com/rustwasm/wasm-bindgen/tree/master/crates/cli-support"
|
|
|
|
homepage = "https://rustwasm.github.io/wasm-bindgen/"
|
|
|
|
documentation = "https://docs.rs/wasm-bindgen-cli-support"
|
2018-03-05 20:24:35 -08:00
|
|
|
description = """
|
|
|
|
Shared support for the wasm-bindgen-cli package, an internal dependency
|
|
|
|
"""
|
Migrate `wasm-bindgen` to using `walrus`
This commit moves `wasm-bindgen` the CLI tool from internally using
`parity-wasm` for wasm parsing/serialization to instead use `walrus`.
The `walrus` crate is something we've been working on recently with an
aim to replace the usage of `parity-wasm` in `wasm-bindgen` to make the
current CLI tool more maintainable as well as more future-proof.
The `walrus` crate provides a much nicer AST to work with as well as a
structured `Module`, whereas `parity-wasm` provides a very raw interface
to the wasm module which isn't really appropriate for our use case. The
many transformations and tweaks that wasm-bindgen does have a huge
amount of ad-hoc index management to carefully craft a final wasm
binary, but this is all entirely taken care for us with the `walrus`
crate.
Additionally, `wasm-bindgen` will ingest and rewrite the wasm file,
often changing the binary offsets of functions. Eventually with DWARF
debug information we'll need to be sure to preserve the debug
information throughout the transformations that `wasm-bindgen` does
today. This is practically impossible to do with the `parity-wasm`
architecture, but `walrus` was designed from the get-go to solve this
problem transparently in the `walrus` crate itself. (it doesn't today,
but this is planned work)
It is the intention that this does not end up regressing any
`wasm-bindgen` use cases, neither in functionality or in speed. As a
large change and refactoring, however, it's likely that at least
something will arise! We'll want to continue to remain vigilant to any
issues that come up with this commit.
Note that the `gc` crate has been deleted as part of this change, as the
`gc` crate is no longer necessary since `walrus` does it automatically.
Additionally the `gc` crate was one of the main problems with preserving
debug information as it often deletes wasm items!
Finally, this also starts moving crates to the 2018 edition where
necessary since `walrus` requires the 2018 edition, and in general it's
more pleasant to work within the 2018 edition!
2019-01-31 09:54:23 -08:00
|
|
|
edition = '2018'
|
2017-12-14 19:31:01 -08:00
|
|
|
|
|
|
|
[dependencies]
|
2018-02-06 08:58:15 -08:00
|
|
|
base64 = "0.9"
|
2018-08-01 16:15:09 -05:00
|
|
|
failure = "0.1.2"
|
2019-02-19 08:17:14 -08:00
|
|
|
log = "0.4"
|
Migrate `wasm-bindgen` to using `walrus`
This commit moves `wasm-bindgen` the CLI tool from internally using
`parity-wasm` for wasm parsing/serialization to instead use `walrus`.
The `walrus` crate is something we've been working on recently with an
aim to replace the usage of `parity-wasm` in `wasm-bindgen` to make the
current CLI tool more maintainable as well as more future-proof.
The `walrus` crate provides a much nicer AST to work with as well as a
structured `Module`, whereas `parity-wasm` provides a very raw interface
to the wasm module which isn't really appropriate for our use case. The
many transformations and tweaks that wasm-bindgen does have a huge
amount of ad-hoc index management to carefully craft a final wasm
binary, but this is all entirely taken care for us with the `walrus`
crate.
Additionally, `wasm-bindgen` will ingest and rewrite the wasm file,
often changing the binary offsets of functions. Eventually with DWARF
debug information we'll need to be sure to preserve the debug
information throughout the transformations that `wasm-bindgen` does
today. This is practically impossible to do with the `parity-wasm`
architecture, but `walrus` was designed from the get-go to solve this
problem transparently in the `walrus` crate itself. (it doesn't today,
but this is planned work)
It is the intention that this does not end up regressing any
`wasm-bindgen` use cases, neither in functionality or in speed. As a
large change and refactoring, however, it's likely that at least
something will arise! We'll want to continue to remain vigilant to any
issues that come up with this commit.
Note that the `gc` crate has been deleted as part of this change, as the
`gc` crate is no longer necessary since `walrus` does it automatically.
Additionally the `gc` crate was one of the main problems with preserving
debug information as it often deletes wasm items!
Finally, this also starts moving crates to the 2018 edition where
necessary since `walrus` requires the 2018 edition, and in general it's
more pleasant to work within the 2018 edition!
2019-01-31 09:54:23 -08:00
|
|
|
rustc-demangle = "0.1.13"
|
2019-02-27 12:20:33 -08:00
|
|
|
serde_json = "1.0"
|
2018-04-30 13:22:46 -07:00
|
|
|
tempfile = "3.0"
|
2019-09-10 11:34:45 -07:00
|
|
|
walrus = "0.12.0"
|
2019-08-19 04:21:27 -07:00
|
|
|
wasm-bindgen-anyref-xform = { path = '../anyref-xform', version = '=0.2.50' }
|
|
|
|
wasm-bindgen-shared = { path = "../shared", version = '=0.2.50' }
|
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-09 14:00:04 -07:00
|
|
|
wasm-bindgen-multi-value-xform = { path = '../multi-value-xform', version = '=0.2.50' }
|
2019-08-19 04:21:27 -07:00
|
|
|
wasm-bindgen-threads-xform = { path = '../threads-xform', version = '=0.2.50' }
|
2019-09-16 11:18:06 -07:00
|
|
|
wasm-bindgen-wasm-conventions = { path = '../wasm-conventions', version = '=0.2.50' }
|
2019-08-19 04:21:27 -07:00
|
|
|
wasm-bindgen-wasm-interpreter = { path = "../wasm-interpreter", version = '=0.2.50' }
|
2019-09-10 11:34:45 -07:00
|
|
|
wasm-webidl-bindings = "0.5.0"
|