rustwasm/wasm-bindgen
1
0
Fork 0
mirror of https://github.com/rustwasm/wasm-bindgen.git synced 2024-12-18 07:11:56 +03:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity
4181fb311a
wasm-bindgen/crates/cli-support/Cargo.toml

25 lines
874 B
TOML
Raw Normal View History

Initial commit
2017-12-15 06:31:01 +03:00
[package]
name = "wasm-bindgen-cli-support"
Bump to 0.2.37
2019-02-15 19:16:24 +03:00
version = "0.2.37"
Bump to 0.2.12 (#515) * Bump to 0.2.12 * Update all version numbers and deps * Update all listed authors to `["The wasm-bindgen Developers"]` * Update `repository` links to specific paths for each crate * Update `homepage` links to the online book * Update all links away from `alexcrichton/wasm-bindgen` * Add `#[doc]` directives for HTML URLs * Update more version requirements * Fill out CHANGELOG
2018-07-19 22:57:04 +03:00
authors = ["The wasm-bindgen Developers"]
Prep work for the 0.1 release
2018-03-06 07:24:35 +03:00
license = "MIT/Apache-2.0"
Bump to 0.2.12 (#515) * Bump to 0.2.12 * Update all version numbers and deps * Update all listed authors to `["The wasm-bindgen Developers"]` * Update `repository` links to specific paths for each crate * Update `homepage` links to the online book * Update all links away from `alexcrichton/wasm-bindgen` * Add `#[doc]` directives for HTML URLs * Update more version requirements * Fill out CHANGELOG
2018-07-19 22:57:04 +03: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"
Prep work for the 0.1 release
2018-03-06 07:24:35 +03: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 20:54:23 +03:00
edition = '2018'
Initial commit
2017-12-15 06:31:01 +03:00
[dependencies]
Fix some class import methods and auto gc The runtime functions are now moved to the `wasm-bindgen` crate and are auto-gc'd if they don't end up actually being required.
2018-02-06 19:58:15 +03:00
base64 = "0.9"
Upgrade `failure` and fix deprecation warnings (#605)
2018-08-02 00:15:09 +03:00
failure = "0.1.2"
Fix an assert while deleting table elements LLVM's mergefunc pass may mean that the same descriptor function is used for different closure invocation sites even when the closure itself is different. This typically only happens with LTO but in theory could happen at any time! The assert was tripping when we tried to delete the same function table entry twice, so instead of a `Vec<usize>` of entries to delete this commit switches to a `HashSet<usize>` which should do the deduplication for us and enusre that we delete each descriptor only once. Closes #1264
2019-02-19 19:17:14 +03: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 20:54:23 +03:00
rustc-demangle = "0.1.13"
Add an example of `wasm2asm` and wasm-bindgen This commit adds an example of executing the `wasm2asm` tool to generate asm.js output instead of WebAssembly. This is often useful when supporting older browsers, such as IE 11, that doesn't have native support for WebAssembly.
2018-04-30 23:22:46 +03:00
tempfile = "3.0"
Upgrade to walrus 0.4 Also be sure to have an explicit GC pass!
2019-02-20 00:07:00 +03:00
walrus = "0.4.0"
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.
2018-10-18 18:43:36 +03:00
wasm-bindgen-anyref-xform = { path = '../anyref-xform', version = '=0.2.37' }
Bump to 0.2.37
2019-02-15 19:16:24 +03:00
wasm-bindgen-shared = { path = "../shared", version = '=0.2.37' }
wasm-bindgen-threads-xform = { path = '../threads-xform', version = '=0.2.37' }
wasm-bindgen-wasm-interpreter = { path = "../wasm-interpreter", version = '=0.2.37' }
Reference in New Issue Copy Permalink