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!
This commit migrates all our examples to using `wasm-pack build` to
compile their code and run `wasm-bindgen`. This should make it a bit
easier to understand the examples as there's less to follow during the
build step.
Webpack projects are all using `@wasm-tool/wasm-pack-plugin` as well so
the build step is simple `npm run serve`. Other examples which retain
`build.sh` are just using `wasm-pack build` now
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.
This commit does a few things, including:
* Fixing the generated JS of `wasm-bindgen` to allow polyfills to work.
(a minor tweak of the generated JS)
* All examples are updated to include a Webpack-specific polyfill for
these two types to get examples working in Edge.
* A new page has been added to the guide about supported browsers. This
mentions known caveats like IE 11 requiring `wasm2js` as well as
documenting some `TextEncoder` and `TextDecoder` workarounds for Edge.
Closes#895
Some examples have been failing to load in some browsers, and this
ensures that whenever the promise to load Rust code fails we log any
errors happening instead of accidentally failing silently.
This helped debug a bit in #897
Rejigger Travis slightly to take advantage of build stages to build the
`gh-pages` branch amongst a set of builders, and then when they're all
done we synchronize and deploy the site. For now use S3 as a backing
store for data between jobs.
This commit is a large-ish scale reorganization of our examples. The
main goal here is to have a dedicated section of the guide for example,
and all examples will be listed there. Each example's `README` is now
just boilerplate pointing at the guide along with a blurb about how to
run it.
Some examples like `math` and `smorgasboard` have been deleted as they
didn't really serve much purpose, and others like `closures` have been
rewritten with `web-sys` instead of hand-bound bindings.
Overall it's hoped that this puts us in a good and consistent state for
our examples, with all of them being described in the guide, excerpts
are in the guide, and they're all relatively idiomatically using
`web-sys`.
* Gate `web-sys` APIs on activated features
Currently the compile times of `web-sys` are unfortunately prohibitive,
increasing the barrier to using it. This commit updates the crate to instead
have all APIs gated by a set of Cargo features which affect what bindings are
generated at compile time (and which are then compiled by rustc). It's
significantly faster to activate only a handful of features vs all thousand of
them!
A magical env var is added to print the list of all features that should be
generated, and then necessary logic is added to ferry features from the build
script to the webidl crate which then uses that as a filter to remove items
after parsing. Currently parsing is pretty speedy so we'll unconditionally parse
all WebIDL files, but this may change in the future!
For now this will make the `web-sys` crate a bit less ergonomic to use as lots
of features will need to be specified, but it should make it much more
approachable in terms of first-user experience with compile times.
* Fix AppVeyor testing web-sys
* FIx a typo
* Udpate feature listings from rebase conflicts
* Add some crate docs and such
This commit adds further support for the `Global` attribute to not only emit
structural accessors but also emit functions that don't take `&self`. All
methods on a `[Global]` interface will not require `&self` and will call
functions and/or access properties on the global scope.
This should enable things like:
Window::location() // returns `Location`
Window::fetch(...) // invokes the `fetch` function
Closes#659
