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`.
* Note that after the game of life tutorial there's also wasm-pack tutorials
* Ensure that the hello world example is clear that webpack isn't
required inline in addition to the text on other pages.
Trying to use a proc macro from a 2018 edition crate in a 2018 edition crate that reexports wasm bindgen's output failed before this commit with "could not find `wasm_bindgen` in `{{root}}`".
This commit was made with
rg " ::wasm_bindgen::" --files-with-matches | xargs sed -i 's/::wasm_bindgen::/wasm_bindgen::/g'
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
Official documentation is now available at
https://rustwasm.github.io/docs/wasm-bindgen/, so let's leave this git
repository's documentation purely for our own previewing purposes.
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 migrates all our examples to using `wasm-pack build` to
compile their code and run `wasm-bindgen`. This should make it a bit
easier to understand the examples as there's less to follow during the
build step.
Webpack projects are all using `@wasm-tool/wasm-pack-plugin` as well so
the build step is simple `npm run serve`. Other examples which retain
`build.sh` are just using `wasm-pack build` now
I have removed the "--------------------" separators as they cause a section number to be skipped and hence incorrect section numbering in the left panel TOC.
Take a look at https://rustwasm.github.io/wasm-bindgen/web-sys/index.html left panel, towards the bottom, and you will see that it's jumps from section 3, to 5, to 7 to 9 - which I am assuming is NOT what you wanted.
This commit switches strategies for storing `JsValue` from a heap/stack
to just one heap. This mirrors the new strategy for `JsValue` storage
in #1002 and should make multiplexing those strategies at
`wasm-bindgen`-time much easier.
Instead of having one array which acts as a stack for borrowed values
and one array for a heap of borrowed values, only one JS array is used
for storage of JS values now. This makes `getObject` far simpler by
simply being an array access, but it means that cloning an object now
reserves a new slot instead of reference counting it. If the old
reference counting behavior is needed it's thought that `Rc<JsValue>`
can be used in Rust.
The new "heap" has an initial stack pointer which grows downwards, and a
heap which grows upwards. The heap is a singly-linked-list which is
allocated/deallocated from. The stack grows downwards to zero and
presumably starts generating errors once it underflows. An initial stack
size of 32 is chosen as that should encompass all use cases today, but
we can eventually probably add configuration for this!
Note that the heap is initialized to all `null` for the stack and then
the initial JS values (`undefined`, `null`, `true`, `false`) are pushed
onto the heap in reserved locations.
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
Correction to Pull Request #1035
limira is correct, that particular paragraph is referencing another crate. Considering the wasm-bindgen tutorial links here for the web-sys crate I added another link to the correct cargo link.
Sorry for the mistake.
