This is intended to handle #1458 and #822. These issues stem from
behavior where:
wasm-pack test --node
will actually run both Node.js and browser tests! Two new env vars are
read here, `WASM_BINDGEN_TEST_ONLY_{NODE,WEB}`, which control which
tests are executed by `wasm-bindgen-test-runner`. The intention is that
these will be set by `wasm-pack` to configure which tests are run, and
if test suites are skipped due to the env vars we'll print an
informational message indicating how they can be run.
Closes#822Closes#1458
This commit reverts part of the implementation of [RFC 6]. That RFC
specified that the `--browser` flag was going to be repurposed for the
new "natively loadable as ES module output", but unfortunately the
breakage is far broader than initially expected. It turns out that
`wasm-pack` passes `--browser` by default which means that a change to
break `--browser` would break all historical versions of `wasm-pack`
which is a bit much for now.
To solve this the `--browser` flag is going back to what it represents
on the current released version of `wasm-bindgen` (optimize away some
node.js checks in a few places for bundler-style output) and a new
`--web` flag is being introduced as the new deployment strategy.
[RFC 6]: https://github.com/rustwasm/rfcs/pull/6Closes#1318
This commit is an implementation of [RFC 6] which enables crates to
inline local JS snippets into the final output artifact of
`wasm-bindgen`. This is accompanied with a few minor breaking changes
which are intended to be relatively minor in practice:
* The `module` attribute disallows paths starting with `./` and `../`.
It requires paths starting with `/` to actually exist on the filesystem.
* The `--browser` flag no longer emits bundler-compatible code, but
rather emits an ES module that can be natively loaded into a browser.
Otherwise be sure to check out [the RFC][RFC 6] for more details, and
otherwise this should implement at least the MVP version of the RFC!
Notably at this time JS snippets with `--nodejs` or `--no-modules` are
not supported and will unconditionally generate an error.
[RFC 6]: https://github.com/rustwasm/rfcs/pull/6Closes#1311
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 is split out from #1002 and is intended to fix the tool's handling
of the `start` function. For the most accurate emulation of the wasm ESM
spec I believe we need to defer execution of the start function until
all our exports are wired up which should allow valid cyclical
references during instantiation.
The fix here is to remove the start function, if one is present, and
inject an invocation of it at the end of initialization (after our
exports are wired up). This fixes tests on #1002, but doesn't have any
direct analogue for tests here just yet.
Along the way because multiple files now come out of `wasm2es6js` by
default I've added an `--out-dir` argument as well as `-o` to ensure
that a folder for all outputs can be specified.
This commit adds a new attribute to `#[wasm_bindgen]`: `start`. The
`start` attribute can be used to indicate that a function should be
executed when the module is loaded, configuring the `start` function of
the wasm executable. While this doesn't necessarily literally configure
the `start` section, it does its best!
Only one crate in a crate graph may indicate `#[wasm_bindgen(start)]`,
so it's not recommended to be used in libraries but only end-user
applications. Currently this still must be used with the `crate-type =
["cdylib"]` annotation in `Cargo.toml`.
The implementation here is somewhat tricky because of the circular
dependency between our generated JS and the wasm file that we emit. This
circular dependency makes running initialization routines (like the
`start` shim) particularly fraught with complications because one may
need to run before the other but bundlers may not necessarily respect
it. Workarounds have been implemented for various emission strategies,
for example calling the start function directly after exports are wired
up with `--no-modules` and otherwise working around what appears to be
a Webpack bug with initializers running in a different order than we'd
like. In any case, this in theory doesn't show up to the end user!
Closes#74
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 shaves a little over 2MB off the download locally for Linux,
removing debuginfo (which no one's probably gonna use anyway) as well as
switching from jemalloc to the system allocator.
This commit removes the need for an injected `ConstructorToken` type and
also cleans up the story we have for generating constructors a bit.
After this commit a `constructor()` is omitted entirely if we're in
non-debug mode and there's no actual listed constructor. Additionally we
don't deal with splat arguments and rerouting constructors, Nick was
kind enough to enlighten me about `Object.create` which is creating an
instance without running the constructor!
Instances of an exported type are now created through one of two
methods:
* If `#[wasm_bindgen(constructor)]` is present, then a `constructor` is
generated with the appropriate signature. If a constructor is not
present and we're in debug mode, a throwing constructor is generated.
If we're in release mode and there's no constructor, no constructor is
generated.
* Otherwise if a binding returns an instance of a type (or otherwise
needs to manfuacture an instance, then it will cause an internal
`__wrap` function to be generated. This function will use
`Object.create` to create an instance without running the constructor.
This should ideally clean up our generated JS for classes quite a bit,
making it much more lean-and-mean!
We've gotten a number of reports that the interactive tests are a bit surprising
and confusing (also because it barely prints anything!). Instead let's default
to headless testing which matches the Rust style of testing much better.
The error message for a missing WebDriver binary has been updated with a note of
how to *not* do headless testing and the message for interactive testing was
also updated to display more information as well.
* Tweak the implementation of heap closures
This commit updates the implementation of the `Closure` type to internally store
an `Rc` and be suitable for dropping a `Closure` during the execution of the
closure. This is currently needed for promises but may be generally useful as
well!
* Support asynchronous tests
This commit adds support for executing tests asynchronously. This is modeled
by tests returning a `Future` instead of simply executing inline, and is
signified with `#[wasm_bindgen_test(async)]`.
Support for this is added through a new `wasm-bindgen-futures` crate which is a
binding between the `futures` crate and JS `Promise` objects.
Lots more details can be found in the details of the commit, but one of the end
results is that the `web-sys` tests are now entirely contained in the same test
suite and don't need `npm install` to be run to execute them!
* Review tweaks
* Add some bindings for `Function.call` to `js_sys`
Name them `call0`, `call1`, `call2`, ... for the number of arguments being
passed.
* Use oneshots channels with `JsFuture`
It did indeed clean up the implementation!
This commit starts migrating the `wasm_bindgen` tests to the `wasm_bindgen_test`
framework, starting to assemble the coffin for
`wasm-bindgen-test-project-builder`. Over time all of the tests in
`tests/all/*.rs` should be migrated to `wasm_bindgen_test`, although they may
not all want to go into a monolithic test suite so we can continue to test for
some more subtle situations with `#[wasm_bindgen]`.
In the meantime those, the `tests/all/api.rs` tests can certainly migrate!
This commit adds support to the `wasm-bindgen-test-runner` binary to
perform headless testing via browsers. The previous commit introduced a
local server to serve up files and run tests in a browser, and this
commit adds support for executing that in an automated fashion.
The general idea here is that each browser has a binary that implements
the WebDriver specification. These binaries (typically `foodriver` for
the browser "Foo") are interfaced with using HTTP and JSON messages. The
implementation was simple enough and the crates.io support was lacking
enough that a small implementation of the WebDriver protocol was added
directly to this crate.
Currently Firefox (`geckodriver`), Chrome (`chromedriver`), and Safari
(`safaridriver`) are supported for running tests. The test harness will
recognize env vars like `GECKODRIVER=foo` to specifically use one or
otherwise detects the first driver in `PATH`. Eventually we may wish to
automatically download a driver if one isn't found, but that isn't
implemented yet.
Headless testing is turned on with the `CI=1` env var currently to be
amenable with things like Travis and AppVeyor, but this may wish to grow
an explicit option to run headless tests in the future.
This commit starts to add support for in-browser testing with
`wasm-bindgen-test-runner`. The current idea here is that somehow it'll be
configured and it'll spawn a little HTTP server serving up files from the
filesystem. This has been tested in various ways but isn't hooked up just yet,
wanted to make sure this was somewhat standalone! Future support for actually
running these tests will be coming in later commits.
