The JS iterator protocol uses duck typing and we don't need separate
ArrayIterator and SetIterator etc types, we can have a single iterator type for
the whole protocol.
* Fix running dist builds on tags
* Only run dist builds on tags, no need to run the full matrix.
* Fix dist builds on AppVeyor to include `wasm-bindgen-test-runner.exe`
* Only cache `~/.cargo` on Travis for the guide build, the `target` dir changes
too much to cache it.
Currently it generates a lot of shim functions which delegate to the wasm module
when loaded, but it turns out with `export let` we can just update the bindings!
Instead of exporting a bunch of shims this updates the export functionality to
only update the `export let` directives with the direct values from the wasm
module once the module is done loading.
In addition to being more ergonomic these are much more efficient at reading
large files as they preallocate internally. This provides a nice speed boost
locally, reducing the overhead of `wasm-bindgen-test-runner` from 0.23s to
0.19s, yay!
This commit updates the test runner to only deserialize a `Module` once and then
directly pass it to the `wasm-bindgen` config, avoiding pulling in a public
dependency with the same strategy as the `wasm-gc-api` crate for now.
This reduces the runtime of this step for `wasm-bindgen-test-runner` from ~0.23s
to ~0.19s on my machine.
Since `wasmi` already has a public dependency on `parity_wasm` let's just use
it! A `clone` is much faster than a serialize + parse, reducing a `wasm-bindgen`
invocation on my machine from 0.2s to 0.18s.
Currently the `wasm-gc-api` crate doesn't expose `parity_wasm::Module` as a
public dependency which means that whenever we want to run a GC (which is twice
per `wasm-bindgen` invocation) we have to serialize and reparse the module a
lot! The `wasm-bindgen` has to serialize, `wasm-gc` then parses, `wasm-gc` then
serializes, and `wasm-bindgen` then parses.
This commit sidesteps all of these operations by ensuring that we always use the
same `parity_wasm::Module` instance, even when multiple versions of the
`parity_wasm` crate are in use. We'll get a speed boost when they happen to
align (which they always should for `wasm-bindgen`), but it'll work even if they
aren't aligned (by going through serialization).
Concretely on my machine this takes a `wasm-bindgen` invocation from 0.5s to
0.2s, a nice win!
This is a bit of a refinement of the solution from #548 to make sure that these
statics are only present on the `wasm32-*` targets, as otherwise these
descriptors are completely inert on other platforms!