It looks like these are primarily targeted at informing whether functionality is
either on web workers, windows, or both. For now we'll generate the same
bindings regardless, and users will need to be proactive about what they're
using. In that case there shouldn't be any need for us to process these, so
avoid warning about them!
* Add a test harness to directly execute wasm tests
This commits adds a few new crates and infrastructure to enable comands like:
cargo test --target wasm32-unknown-unknown
The intention here is to make it as low-friction as possible to write wasm tests
and also have them execute in a reasonable amount of time. Eventually this is
also hopefully enough support to do things like headless testing!
For now though this is defintely MVP status rather than fully fleshed out.
There's some more information at `crates/test/README.md` about how it works and
how to use it, but for now this is mainly intended to play around with locally
in this repository for our own tests.
* Port a numbe of `js-sys` tests to the new test framework
This commit ports a number of existing tests for the `js-sys` crate over to the
new test framework created in the previous commit, showing off how they can be
executed as well as drastictlly simplifying the tests themselves! This is
intended to be a proof of concept for now which we can refine over time. This
should also show off that it's possible to incrementally move over to the new
test framework.
* Add some notes about viewing bindings output.
I found this helpful when debugging, so I thought others might too.
* Fix formatting
* Another formatting fix
* Bump to 0.2.12
* Update all version numbers and deps
* Update all listed authors to `["The wasm-bindgen Developers"]`
* Update `repository` links to specific paths for each crate
* Update `homepage` links to the online book
* Update all links away from `alexcrichton/wasm-bindgen`
* Add `#[doc]` directives for HTML URLs
* Update more version requirements
* Fill out CHANGELOG
* Shard the `convert.rs` module into sub-modules
Hopefully this'll make the organization a little nicer over time!
* Start adding support for optional types
This commit starts adding support for optional types to wasm-bindgen as
arguments/return values to functions. The strategy here is to add two new
traits, `OptionIntoWasmAbi` and `OptionFromWasmAbi`. These two traits are used
as a blanket impl to implement `IntoWasmAbi` and `FromWasmAbi` for `Option<T>`.
Some consequences of this design:
* It should be possible to ensure `Option<SomeForeignType>` implements to/from
wasm traits. This is because the option-based traits can be implemented for
foreign types.
* A specialized implementation is possible for all types, so there's no need for
`Option<T>` to introduce unnecessary overhead.
* Two new traits is a bit unforutnate but I can't currently think of an
alternative design that works for the above two constraints, although it
doesn't mean one doesn't exist!
* The error messages for "can't use this type here" is actually halfway decent
because it says these new traits need to be implemented, which provides a good
place to document and talk about what's going on here!
* Nested references like `Option<&T>` can't implement `FromWasmAbi`. This means
that you can't define a function in Rust which takes `Option<&str>`. It may be
possible to do this one day but it'll likely require more trait trickery than
I'm capable of right now.
* Add support for optional slices
This commit adds support for optional slice types, things like strings and
arrays. The null representation of these has a pointer value of 0, which should
never happen in normal Rust. Otherwise the various plumbing is done throughout
the tooling to enable these types in all locations.
* Fix `takeObject` on global sentinels
These don't have a reference count as they're always expected to work, so avoid
actually dropping a reference on them.
* Remove some no longer needed bindings
* Add support for optional anyref types
This commit adds support for optional imported class types. Each type imported
with `#[wasm_bindgen]` automatically implements the relevant traits and now
supports `Option<Foo>` in various argument/return positions.
* Fix building without the `std` feature
* Actually fix the build...
* Add support for optional types to WebIDL
Closes#502
* Move the `js` module to a `js_sys` crate
* Update js-sys tests to pass again
* Update binding_to_unimplemented_apis_doesnt_break_everything
Remove its dependency on the `js` module
* Update metadata for js-sys
* Fix the `closures` example
Add support for the primitive type arrays, and additionally switch `ByteString`
to `String` instead of `Vec<u8>` according to the online documentation.
Not a lot of attention has been paid to dealing with conflicts of symbols
between crates and different `#[wasm_bindgen]` blocks. This commit starts to fix
this issue by unblocking #486 which first ran into this. Currently there's a bug
where if two independent crates bind the same JS API they'll generate the same
symbol which causes conflicts for things like LTO or linking in general.
This commit starts to add a "salt" to all symbols generated by `wasm-bindgen`
(these are all transparent to the user) to ensure that each crate's invocations
are kept apart from one another and using the correct bindings.
This commit adds a hack to the `wasm-bindgen` CLI tool to work around #483 which
is present on nightly Rust with the recent LLVM upgrade. Hopefully this'll carry
us forward until the [upstream bug][1] is fixed.
Closes#483
[1]: https://bugs.llvm.org/show_bug.cgi?id=38184
* clippy: it is more idiomatic to loop over references to containers instead of using explicit iteration methods
* clippy: useless use of `format!`
* clippy: if/else is an expression
* clippy: use of followed by a function call
* clippy: large size difference between variants
* clippy: redundant closure
* Revert "clippy: large size difference between variants"
This reverts commit 7e2e660dd4.
* Revert "clippy: it is more idiomatic to loop over references to containers instead of using explicit iteration methods"
This reverts commit 5c4804f790.
This test fails on my system. As previously decided, until we can
figure out a better solution for this issue, for now we just check
to make sure the output is a non-empty string.
