* Pre-generating web-sys
* Fixing build errors
* Minor refactor for the unit tests
* Changing to generate #[wasm_bindgen} annotations
* Fixing code generation
* Adding in main bin to wasm-bindgen-webidl
* Fixing more problems
* Adding in support for unstable APIs
* Fixing bug with code generation
* More code generation fixes
* Improving the webidl program
* Removing unnecessary cfg from the generated code
* Splitting doc comments onto separate lines
* Improving the generation for unstable features
* Adding in support for string values in enums
* Now runs rustfmt on the mod.rs file
* Fixing codegen for constructors
* Fixing webidl-tests
* Fixing build errors
* Another fix for build errors
* Renaming typescript_name to typescript_type
* Adding in docs for typescript_type
* Adding in CI script to verify that web-sys is up to date
* Fixing CI script
* Fixing CI script
* Don't suppress git diff output
* Remove duplicate definitions of `Location`
Looks to be a preexisting bug in wasm-bindgen?
* Regenerate webidl
* Try to get the git diff command right
* Handle named constructors in WebIDL
* Remove stray rustfmt.toml
* Add back NamedConstructorBar definition in tests
* Run stable rustfmt over everything
* Don't run Cargo in a build script
Instead refactor things so webidl-tests can use the Rust-code-generation
as a library in a build script. Also fixes `cargo fmt` in the
repository.
* Fixup generated code
* Running web-sys checks on stable
* Improving the code generation a little
* Running rustfmt
Co-authored-by: Alex Crichton <alex@alexcrichton.com>
* Add support for #[wasm_bindgen(inspectable)]
This annotation generates a `toJSON` and `toString` implementation for
generated JavaScript classes which display all readable properties
available via the class or its getters
This is useful because wasm-bindgen classes currently serialize to
display one value named `ptr`, which does not model the properties of
the struct in Rust
This annotation addresses rustwasm/wasm-bindgen#1857
* Support console.log for inspectable attr in Nodejs
`#[wasm_bindgen(inspectable)]` now generates an implementation of
`[util.inspect.custom]` for the Node.js target only. This implementation
causes `console.log` and friends to yield the same class-style output,
but with all readable fields of the Rust struct displayed
* Reduce duplication in generated methods
Generated `toString` and `[util.inspect.custom]` methods now call
`toJSON` to reduce duplication
* Store module name in variable
This came up during #1760 where `Promise.resolve` must be invoked with
`this` as the `Promise` object, but we were erroneously importing it in
such a way that it didn't have a shim and `this` was `undefined`.
This commit adds support to attach `#[wasm_bindgen]` on an `async fn`
which will change the return value into a `Promise` in JS. This in
theory has the exact same semantics as an `async` function in JS where
you call it with all the arguments, nothing happens and you get a
promise back, and then later the promise actually resolves.
This commit also adds a helper trait, `IntoJsResult`, to allow `async`
functions with multiple kinds of return values instead of requiring
everything to be `Result<JsValue, JsValue>`.
* Update browser support for `BigInt`
`BigInt` is supported in Firefox as of Firefox 68!
Also replaced Firefox with Safari as a second example of an unsupported browser.
* Add link to "BigInt" on "Can I use..."
This commit aims to address #1348 via a number of strategies:
* Documentation is updated to warn about UTF-16 vs UTF-8 problems
between JS and Rust. Notably documenting that `as_string` and handling
of arguments is lossy when there are lone surrogates.
* A `JsString::is_valid_utf16` method was added to test whether
`as_string` is lossless or not.
The intention is that most default behavior of `wasm-bindgen` will
remain, but where necessary bindings will use `JsString` instead of
`str`/`String` and will manually check for `is_valid_utf16` as
necessary. It's also hypothesized that this is relatively rare and not
too performance critical, so an optimized intrinsic for `is_valid_utf16`
is not yet provided.
Closes#1348
This commit deprecates the `--web`, `--no-modules`, and `--nodejs` flags
in favor of one `--target` flag. The motivation for this commit is to be
consistent between `wasm-bindgen` and `wasm-pack` so documentation for
one is applicable for the other (so we don't have to document everywhere
what the translation is between flags). Additionally this should make it
a bit easier to add new targets (if necessary) in the future as it won't
add to the proliferation of flags.
For now the old flags (like `--web`) continue to be accepted, but
they'll be removed during the next set of breaking changes for
`wasm-bindgen`.
This allows subverting the checks and resolution performed by the
`module` attribute added as part of [RFC 6] and has been discussed in #1343.
Closes#1343
[RFC 6]: https://github.com/rustwasm/rfcs/pull/6
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 rejiggers some documentation of `wasm-bindgen` in a few
significant ways:
* The main landing page now has text and links to the Game of Life
tutorial and `wasm-pack`.
* The "whirlwind tour" was deleted as it wasn't really serving any
purpose that the Game of Life plus the later references weren't already
serving.
* The "no modules" example was renamed to "without a bundler"
* A dedicated section on "Deployment" was added which replaces the
previous "No ES Modules" page. This is hopefully more descriptive and
also prominently mentions the various options for deployment.
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
This commit switches all imports of JS methods to `structural` by
default. Proposed in [RFC 5] this should increase the performance of
bindings today while also providing future-proofing for possible
confusion with the recent addition of the `Deref` trait for all imported
types by default as well.
A new attribute, `host_binding`, is introduced in this PR as well to
recover the old behavior of binding directly to an imported function
which will one day be the precise function on the prototype. Eventually
`web-sys` will switcsh over entirely to being driven via `host_binding`
methods, but for now it's been measured to be not quite as fast so we're
not making that switch yet.
Note that `host_binding` differs from the proposed name of `final` due
to the controversy, and its hoped that `host_binding` is a good
middle-ground!
[RFC 5]: https://rustwasm.github.io/rfcs/005-structural-and-deref.html
I've noticed this in a few cases where it's sometimes easy to have a
`WebAssembly.Module` on-hand for the `--no-modules` mode where you don't
want to necessarily `fetch`. This commit changes the exported
initialization function in `--no-modules` mode to support both!
This commit does a few things, including:
* Fixing the generated JS of `wasm-bindgen` to allow polyfills to work.
(a minor tweak of the generated JS)
* All examples are updated to include a Webpack-specific polyfill for
these two types to get examples working in Edge.
* A new page has been added to the guide about supported browsers. This
mentions known caveats like IE 11 requiring `wasm2js` as well as
documenting some `TextEncoder` and `TextDecoder` workarounds for Edge.
Closes#895
