Previously `arguments` was used to pass around an array of arguments,
but this wasn't actually a `js_sys::Array` but rather a somewhat
esoteric internal object. When switching over `Array` methods to be
`structural` this caused issues because the inherent methods on an
`arguments` object were different than that of `js_sys::Array`.
This commit implements the first half of [RFC #5] where the `Deref`
trait is implemented for all imported types. The target of `Deref` is
either the first entry of the list of `extends` attribute or `JsValue`.
All examples using `.as_ref()` with various `web-sys` types have been
updated to the more ergonomic deref casts now. Additionally the
`web-sys` generation of the `extends` array has been fixed slightly to
explicitly list implementatoins in the hierarchy order to ensure the
correct target for `Deref` is chosen.
[RFC #5]: https://github.com/rustwasm/rfcs/blob/master/text/005-structural-and-deref.md
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.
For example, the constructor in Response.webidl accepts multiple types. However, one of those types is `ReadableStream` which isn't defined yet, and that causes all constructors for Response to be skipped even though the other argument types could be supported.
This commit makes the `to_idl_type` infallible, returning a new enum
variant, `UnknownInterface`, in the one location that we still return
`None`. By making this infallible we can ensure that expansion of unions
which have unknown types still generate methods for all the variants
which we actually have all the methods for!
This commit adds a test harness and the beginnings of a test suite for
the crate that performs GC over a wasm module. This crate historically
has had zero tests because it was thought that it would no longer be
used once LLD landed with `--gc-sections`, but `wasm-bindgen` has come
to rely more and more on `wasm-gc` for various purposes.
The last release of `wasm-bindgen` was also released with a bug in the
recently refactored support in the `wasm-gc` crate, providing a perfect
time and motivation to start writing some tests!
All tests added here are `*.wat` files which contain the expected output
after the gc pass is executed. Tests are automatically updated with
`BLESS_TESTS=1` in the environment, which is the expected way to
generate the output for each test.
This commit updates the `wasm-gc` pass of wasm-bindgen to eliminate
duplicate types in the type section, effectively enabling a gc of the
type section itself. The main purpose here is ensure that code generated
by `wasm-bindgen` itself doesn't have to go too far out of its way to
deduplicate at generation time, but rather it can rely on the gc pass to
clean up.
Note that this currently depends on paritytech/parity-wasm#231, but this
can be updated if that ends up not landing.
This commit adds support for running a gc pass over locals in a
function. This will remove dead local declarations for a function
(completely unused) as well as compact existing entries to ensure that
we don't have two local declarations of the same type.
While this was initially intended for some future support of emitting
shims in `wasm-bindgen`, it turns out this pass is firing quite a lot
over existing functions generated by LLVM. Looks like we may see benefit
from this today with slightly smaller wasm binaries!
This configures sccache for Linux/OSX/Windows in an attempt to speed up
CI by reusing the results of previous builds, cached on the network with
`sccache`.
These don't seem to be widely used and they're not needed by
wasm-bindgen itself, so let's remove the symbols by default and
optionally in the future we can add an option to retain them.
This commit restructures some of the internals of `wasm-gc` now that
I've actually got a better grasp on the wasm format and what all the
ownership edges look like. This shouldn't actually result in any
user-facing changes, but should make us be a bit more compatible with
operations in the future.
Memories/tables/elements/segments are no longer considered automatic
roots but rather need to be rooted by something else to prevent a gc.
For example an element section is gc'd along with a table if the table
is never referenced, along with data segments as well if the memory
isn't referenced.
Additionally all index sets now don't contained offseted indices, but
rather everything is always stored relative to the "index space" to
ensure consistency.
This should make it a bit easier to add future items to gc!
While technically correct the current implementation sort of made it
only roundaboutedly so. Tweak the logic a bit and the associated comment
to ensure that stack values are never dropped and the global constants
are all skipped.
Previously whenever a future readiness notification came in we would
immediately start polling a future. This ends up having two downsides,
however:
* First, the stack depth may run a risk of getting blown. There's no
recursion limit to defer execution to later, which means that if
futures are always ready we'll keep making the stack deeper.
* Second, and more worrisome in the near term, apparently future
adapaters in the `futures` crate (namely the unsync oneshot channel)
doesn't actually work if you immediately poll on readiness. This may
or may not be a bug in the `futures` crate but it's good to fix it
here anyway.
As a result whenever a future is ready to get polled again we defer its
polling to the next turn of the event loop. This should ensure that the
current call stack is always drained and we're effectively enqueueing
the future to be polled in the near future.
