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.
* Make ConvertToAst trait fallible
It's got some panics, and we'll be switching those to errors!
* First example of a diagnostic-driven error
Add a diagnostic-driven error `#[wasm_bindgen]` being attached to public
functions, and add some macros to boot to make it easier to generate errors!
* Result-ify `src/parser.rs`
This commit converts all of `src/parser.rs` away from panics to using
`Diagnostic` instead. Along the way this adds a test case per changed `panic!`,
ensuring that we don't regress in these areas!
* Use ES modules in README example
* Remove introduction blog post from README
While the blog post is great, the README and the guide should be a good enough
intro to wasm-bindgen, and are more likely to be kept up to date.
This commit starts to add infrastructure for targeted diagnostics in the
`#[wasm_bindgen]` attribute, intended eventually at providing much better errors
as they'll be pointing to exactly the code in question rather than always to a
`#[wasm_bindgen]` attribute.
The general changes are are:
* A new `Diagnostic` error type is added to the backend. A `Diagnostic` is
created with a textual error or with a span, and it can also be created from a
list of diagnostics. A `Diagnostic` implements `ToTokens` which emits a bunch
of invocations of `compile_error!` that will cause rustc to later generate
errors.
* Fallible implementations of `ToTokens` have switched to using a new trait,
`TryToTokens`, which returns a `Result` to use `?` with.
* The `MacroParse` trait has changed to returning a `Result` to propagate errors
upwards.
* A new `ui-tests` crate was added which uses `compiletest_rs` to add UI tests.
These UI tests will verify that our output improves over time and does not
regress. This test suite is added to CI as a new builder as well.
* No `Diagnostic` instances are created just yet, everything continues to panic
and return `Ok`, with the one exception of the top-level invocations of
`syn::parse` which now create a `Diagnostic` and pass it along.
This commit does not immediately improve diagnostics but the intention is that
it is laying the groundwork for improving diagnostics over time. It should
ideally be much easier to contribute improved diagnostics after this commit!
cc #601
* 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!
In an actual browser, the changing of the history using the binding
worked a little too well, and caused the test to fail if you refreshed
the page or manually used the back and forward buttons. The stateful
stuff has been removed - the remaining two assertions should adequately
test that the binding works, which is the point of these tests anyways.
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 updates the test harness for in-browser testing. It now no longer
unconditionally uses `fs.writeSync`, for example. Instead a `Formatter` trait is
introduced for both Node/browser environments and at runtime we detect which is
the appropriate one to use.
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.
