The WebIDL-based -sys crate will also use this, but I want its tests to be a
separate suite that we can run separately and in parallel in CI. Therefore, this
testing infrastructure code needs to be share-able between them :)
* tests: Add newlines between impl methods for Project
* WIP headless browser testing with geckodriver and selenium
* Get some more of headless testing working
* Extract `console.log` invocations and print them from the console
* Ship the error message from an exception from the browser back to the command
line
* Cleanup some "if headless" and `else` branches
* Fix killing `webpack-dev-server` in the background with `--watch-stdin`
* Fix path appending logic for Windows
* Always log logs/errors in headless mode
* Install Firefox on Travis
* Don't duplicate full test suite with `yarn`
No need to run that many tests, we should be able to get by with a smoke test
that it just works.
* headless tests: Move `run-headless.js` to its own file and `include_str!` it
* Run `rustfmt` on `tests/all/main.rs`
* guide: Add note about headless browser tests and configuration
* test: Log WASM_BINDGEN_FIREFOX_BIN_PATH in run-headless.js
* TEMP only run add_headless test in CI
* Add more logging to headless testing
* Allow headless tests to run for 60 seconds before timeout
* TEMP add logging to add_headless test
* Fix headless browser tests
* Another attempt to fix Travis
* More attempts at debugging
* Fix more merge conflicts
* Touch up an error message
* Fixup travis again
* Enable all travis tests again
* Test everything on AppVeyor
* Reorganize Travis configuration
* Add a `JOB` env var descriptor to all matrix entries. Not used anywhere but is
useful when viewing the whole build on Travis's web interface.
* Reorganize where builds are located, moving slow builds first and fast ones
last.
* Change checking the CLI builds from `cargo build` to `cargo check`
* Use YAML references to reduce some duplication
* Print some more timing statistics for each test
* Extract `Project` helper in tests to a module
This'll help make it a bit more extensible over time. At the same time the
methods are also slightly reorganized to read more clearly from top to bottom.
* Migrate all tests away from Webpack
Wepback can take a significant amount of time to execute and when it's
multiplied by hundreds of tests that adds up really quickly! After investigating
Node's `--experimental-modules` option it looks like it's suitable for our use
so this switches all tests to using JS files (moving away from TypeScript as
well) with `--experimental-modules` with Node.
Tests will be selectively re-enabled with webpack and node.js specific output
(that doesn't require `--experimental-modules`), coming in later commits.
* Restore the node test for node.js output
Ensures it's workable as-is
* Only generate typescript with webpack
* Only read wasm files for webpack
* Skip package.json/node_modules for now
* Only generate webpack config if needed
* Start a dedicated test module for typescript
Will hopefully verify the generated Typescript compiles OK.
* Remove unneeded `node` method
* Fixup some rebase conflicts
* Don't run asmjs example on travis
* Fixup generator tests
* Attempt to fix windows
* Comment windows fix
* More test fixes
* More exclusions
* More test fixes
* Relax eslint regex
Catch mjs modules as well
* Fix eslint
* Speed up travis on examples slightly
* No need for version deps in dev-deps
These are all internal so we can drop the version
* Remove wasm-bindgen-cli's parity-wasm dep
No longer needed
* Tweak file hierarchy in webidl tests
Use Cargo's conventions to avoid the need to define `[[test]]` sections
* Remove unused imports
If a JS import's shim isn't actually imported that means that somewhere along
the way it was optimized out or it was never used in the first place! In that
case we can skip generation of the JS bindings for it as it's not needed.
These are bindings to JavaScript's standard, built-in objects and their methods
and properties.
This does *not* include any Web, Node, or any other JS environment APIs. Only
the things that are guaranteed to exist in the global scope by the ECMAScript
standard.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects
* backend comments complete
* better matching
* gen comments
* Add example
* Move test bindings gen to own fn
* move build step into build fn
* add fn to read js, refactor gen_bindings/test to allow for this
* Add comments test
* Update readmes
* add comments to travis
* fix broken tests
* +x on build.sh
* fix wbg cmd in build.sh
* Address fitzgen's comments
Awhile back slices switched to being raw views into wasm memory, but this
doens't work if we free the underlying memory unconditionally! Moving around a
`Vec` is already moving a lot of data, so let's copy it onto the JS heap instead
of leaving it in the wasm heap.
This commit is an implementation of mapping u64/i64 to `BigInt` in JS through
the unstable BigInt APIs. The BigInt type will ship soon in Chrome and so this
commit builds out the necessary support for wasm-bindgen to use it!
When adding support for mutable slices I was under the impression that if the
wasm memory was reallocated while we were using it then we'd have to commit the
changes from the original buffer back to the new buffer. What I didn't know,
however, is that once the wasm memory is reallocated then all views into it are
supposed to be defunkt.
It looks like node 9 didn't have this implementation quite right and it appears
fixed in node 10, causing the deleted test here to fail. While this commit does
raise the question of whether this is the right approach to interact with slices
in JS I think the answer is still "yes". The user can always initiate the copy
if need be and that seems strictly better than copying 100% of the time.
This commit updates the `Abi` associated type for all slice types to a
`WasmSlice` type, an aggregate of two `u32` integers. This translates to an ABI
where when passed as a function argument it expands to two integer arguments,
and when passed as a return value it passes a return pointer as the first
argument to get filled in.
This is hopefully more forwards-compatible with the host bindings proposal which
uses this strategy for passing string arguments at least. It's a little sketchy
what we're doing as there's not really a stable ABI yet, but hopefully this'll
all be relatively stable for awhile!
This commit adds support for mutable slices to pass the boundary between JS and
Rust. While mutable slices cannot be used as return values they can be listed as
arguments to both exported functions as well as imported functions.
When passing a mutable slice into a Rust function (aka having it as an argument
to an exported Rust function) then like before with a normal slice it's copied
into the wasm memory. Afterwards, however, the updates in the wasm memory will
be reflected back into the original slice. This does require a lot of copying
and probably isn't the most efficient, but it should at least work for the time
being.
The real nifty part happens when Rust passes a mutable slice out to JS. When
doing this it's a very cheap operation that just gets a subarray of the main
wasm memory. Now the wasm memory's buffer can change over time which can produce
surprising results where memory is modified in JS but it may not be reflected
back into Rust. To accomodate this when a JS imported function returns any
updates to the buffer are copied back to Rust if Rust's memory buffer has
changed in the meantime.
Along the way this fixes usage of `slice` to instead use `subarray` as that's
what we really want, no copying. All methods have been updated to use `subarray`
accessors instead of `slice` or constructing new arrays.
Closes#53
Currently `#[wasm_bindgen]` generates a bunch of references to symbols that
don't actually exist on non-wasm targets, making it more difficult to get a
crate working across multiple platforms. This commit updates the symbol
references to be dummy ones that panic on non-wasm targets to allow simple
testing/benchmarking to work on native targets.
While this isn't a perfect solution for #114 it's probably as good as we can do
for now pending upstream Cargo features, so I'm gonna say that it...
Closes#114
These functions are activated with the `serde-serialization` feature of the
`wasm-bindgen` crate. When activated they will allow passing any arbitrary value
into JS that implements the `Serialize` trait and receiving any value from JS
using the `Deserialize` trait. The interchange between JS and Rust is JSON.
Closes#96
This commit adds a `#[wasm_bindgen(version = "...")]` attribute support. This
information is eventually written into a `__wasm_pack_unstable` section.
Currently this is a strawman for the proposal in ashleygwilliams/wasm-pack#101
Turns out there was a bug when passing a vector of `JsValue` instances back to
JS all objects were leaked rather than correctly removed from the global slab.
This commit fixes how the `getArrayJsValueFromWasm` function is defined to
correctly iterate over the slice by looking at the values rather than the
indices.
Closes#169
Add support for `#[wasm_bindgen(readonly)]` which indicates that an exported
struct field is readonly and attempting to set it in JS will throw an exception.
Closes#151
Automatically infer public struct fields as "JS wants to access this" and
generate appropriate getters/setters for the field. At this time the field is
required to implement `Copy`, but we will probably want to relax that in the
future to at least encompass `JsValue` and maybe other `Clone` values as well.
Closes#121
This commit adds support for both `#![no_std]` in the wasm-bindgen runtime
support (disabled by default with an on-by-default `std` feature). This also
adds support to work and compile in the context of `#![no_std]` crates.
Closes#146
This commit adds support for closures with arguments like strings and such. In
other words, closures passed to JS can now have the same suite of arguments as
all functions that can be exported from Rust, as one might expect!
At this time due to the way trait objects work closures still cannot use types
with references like `&str`, but bare values like `String` or `ImportedType`
should work just fine.
Closes#104
This commit adds support for passing `&mut FnMut(..)` to JS via imports. These
closures cannot be invoked recursively in JS (they invalidate themselves while
they're being invoked) and otherwise work the same as `&Fn(..)` closures.
Closes#123
Nowadays the compile times are mitigated with incremental compilation and
otherwise it's much more ergonomic to run only one test if they're all in the
same suite.
This commit starts wasm-bindgen down the path of supporting closures. We
discussed this at the recent Rust All-Hands but I ended up needing to pretty
significantly scale back the ambitions of what closures are supported. This
commit is just the initial support and provides only a small amount of support
but will hopefully provide a good basis for future implementations.
Specifically this commit adds support for passing `&Fn(...)` to an *imported
function*, but nothing elese. The `&Fn` type can have any lifetime and the JS
object is invalidated as soon as the import returns. The arguments and return
value of `Fn` must currently implement the `WasmAbi` trait, aka they can't
require any conversions like strings/types/etc.
I'd like to soon expand this to `&mut FnMut` as well as `'static` closures that
can be passed around for a long time in JS, but for now I'm putting that off
until later. I'm not currently sure how to implement richer argument types, but
hopefully that can be figured out at some point!
