Reported in #1191 the fix requires us to get a bit creative I think. The
general gist is that a block like this:
#[wasm_bindgen]
impl Foo {
pub fn foo() {}
}
was previously expanded all in one go. Now, however, it's expanded into:
impl Foo {
#[__wasm_bindgen_class_marker(Foo = "Foo")]
pub fn foo() {}
}
// goop generated by orginal #[wasm_bindgen]
This method of expansion takes advantage of rustc's recursive expansion
feature. It also allows us to expand `impl` blocks and allow inner items
to not be fully expanded yet, such as still having `#[cfg]` attributes
(like in the original bug report).
We use theinternal `__wasm_bindgen_class_marker` to indicate that we're
parsing an `ImplItemMethod` unconditionally, and then generation
proceeds as usual. The only final catch is that when we're expanding in
an `impl` block we have to generate tokens for the `Program`
(wasm-bindgen injected goop like the custom section) inside the body
of the function itself instead of next to it. Otherwise we'd get syntax
errors inside of impl blocks!
Closes#1191
This commit updates the `--debug` output of `wasm-bindgen` from the CLI
to catch all JS exceptions from imported functions, log such, and then
rethrow. It's hoped that this can be used when necessary to learn more
information about thrown exceptions and where an uncaught exception
could be causing issues with Rust code.
Closes#1176
Throw it in an `Option` and then `take()` it when we consume it to
ensure that future calls to insert data into it panic instead of
producing inconsistent JS.
This was removed when mozilla specific extensions were removed. It is not
mozilla specific though and currently the only way to show webcam data in
a video element that I am aware of.
For all typed arrays, this commit adds:
* `TypedArray::view(src: &[Type])`
* `TypedArray::copy_to(&self, dst: &mut [Type])`
The `view` function is unsafe because it doesn't provide any guarantees
about lifetimes or mutability. The `copy_to` function is, however, safe.
Closes#811
We might gc a table away so if we need to export it be sure to do so
before we gc! Additionally remove an extraneous gc that snuck in at some
point, no need to do more than one.
Closes#1130
Turns out `heap.fill(undefined)` is required to ensure it's a dense
array, otherwise we'll accidentally be a sparse array and much slower
than necessary!
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.
Previously `catch` and `variadic` would exopse methods in our JS shims,
but they did so earlier than necessary. Turns out `variadic` didn't
actually need to expose anything and `catch` could do so much later!
Currently closure shims are communicated to JS at runtime, although at
runtime the same constant value is always passed to JS! More pressing,
however, work in #1002 requires knowledge of closure descriptor indices
at `wasm-bindgen` time which is not currently known.
Since the closure descriptor shims and such are already constant values,
this commit moves the descriptor function indices into the *descriptor*
for a closure/function pointer. This way we can learn about these values
at `wasm-bindgen` time instead of only knowing them at runtime.
This should have no semantic change on users of `wasm-bindgen`, although
some closure invocations may be slightly speedier because there's less
arguments being transferred over the boundary. Overall though this will
help #1002 as the closure shims that the Rust compiler generates may not
be the exact ones we hand out to JS, but rather wrappers around them
which do `anyref` business things.
This commit fixes a case in `wasm2es6js` where if an imported function
was reexported it wasn't handled correctly. This doesn't have a direct
test but came up during the development of #1002
This is split out from #1002 and is intended to fix the tool's handling
of the `start` function. For the most accurate emulation of the wasm ESM
spec I believe we need to defer execution of the start function until
all our exports are wired up which should allow valid cyclical
references during instantiation.
The fix here is to remove the start function, if one is present, and
inject an invocation of it at the end of initialization (after our
exports are wired up). This fixes tests on #1002, but doesn't have any
direct analogue for tests here just yet.
Along the way because multiple files now come out of `wasm2es6js` by
default I've added an `--out-dir` argument as well as `-o` to ensure
that a folder for all outputs can be specified.
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 implements a system that will assert that all
`#[wasm_bindgen]` attributes are actually used during compilation. This
should help ensure that we don't sneak in stray attributes that don't
actually end up having any meaning, and hopefully make it a bit easier
to learn `#[wasm_bindgen]`!
This generates a `*.d.ts` file for the wasm file that wasm-bindgen emits
whenever typescript is enable *in addition* to the `*.d.ts` file that
already exists for the JS shim.
Closes#1040
Recently proposed in WebAssembly/tool-conventions#65 each wasm file will
now have an optional `producers` section listing the tooling that went
into producing it. Let's add `wasm-bindgen` in when it processes a wasm
file!
This commit adds an optimization to `wasm-bindgen` to directly import
and invoke other modules' functions from the wasm module, rather than
going through a shim in the imported bindings. This will be an important
optimization in the future for the host bindings proposal, but for now
it's largely just a proof-of-concept to show that we can do it and is
unlikely to bring about many performance benefits.
The implementation in this commit is largely refactoring to reorganize a
bit how functions are imported, but the implementation happens in
`generate_import_function`.
With this commit, 71/287 imports in the `tests/wasm/main.rs` suite get
hooked up directly to the ES modules, no shims needed!
When returning a ptr/length for allocations and such wasm-bindgen's
generated JS would previously return an array with two elements. It
turns out this doesn't optimize well in all engines! (See #1031). It
looks like we can optimize the array destructuring a bit more, but this
is all generated code which doesn't need to be too readable so we can
also remove the temporary allocation entirely and just pass the second
element of this array through a global instead of the return value.
Closes#1031
This fixes a mistake in allowing a `WebAssembly.Module` to be passed to
the initialization function in `--no-modules` mode by ensuring that it
resolves to a map of an instance/module instead of just resolving to an
instance.
This commit adds a `--remove-name-section` flag to the `wasm-bindgen`
command which will remove the `name` section of the wasm file, used to
indicate the names of functions typically used in debugging. This flag
is off-by-default and will primarily be controlled by wasm-pack,
typically being passed by default with `wasm-pack build --release`.
Closes#1021
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
This commit removes shims, where possible, for `structural` items.
Instead of generating code that looks like:
const target = function() { this.foo(); };
exports.__wbg_thing = function(a) { target.call(getObject(a)); };
we now instead generate:
exports.__wbg_thing = function(a) { getObject(a).foo(); };
Note that this only applies to `structural` bindings, all default
bindings (as of this commit) are still using imported targets to ensure
that their binding can't change after instantiation.
This change was [detailed in RFC #5][link] as an important optimization
for `structural` bindings to ensure they've got performance parity with
today's non-`structural` default bindings.
[link]: https://rustwasm.github.io/rfcs/005-structural-and-deref.html#why-is-it-ok-to-make-structural-the-default
Previously `arguments` was used to pass around an array of arguments,
but this wasn't actually a `js_sys::Array` but rather a somewhat
esoteric internal object. When switching over `Array` methods to be
`structural` this caused issues because the inherent methods on an
`arguments` object were different than that of `js_sys::Array`.
This commit implements the first half of [RFC #5] where the `Deref`
trait is implemented for all imported types. The target of `Deref` is
either the first entry of the list of `extends` attribute or `JsValue`.
All examples using `.as_ref()` with various `web-sys` types have been
updated to the more ergonomic deref casts now. Additionally the
`web-sys` generation of the `extends` array has been fixed slightly to
explicitly list implementatoins in the hierarchy order to ensure the
correct target for `Deref` is chosen.
[RFC #5]: https://github.com/rustwasm/rfcs/blob/master/text/005-structural-and-deref.md
For example, the constructor in Response.webidl accepts multiple types. However, one of those types is `ReadableStream` which isn't defined yet, and that causes all constructors for Response to be skipped even though the other argument types could be supported.
This commit makes the `to_idl_type` infallible, returning a new enum
variant, `UnknownInterface`, in the one location that we still return
`None`. By making this infallible we can ensure that expansion of unions
which have unknown types still generate methods for all the variants
which we actually have all the methods for!
This commit adds a test harness and the beginnings of a test suite for
the crate that performs GC over a wasm module. This crate historically
has had zero tests because it was thought that it would no longer be
used once LLD landed with `--gc-sections`, but `wasm-bindgen` has come
to rely more and more on `wasm-gc` for various purposes.
The last release of `wasm-bindgen` was also released with a bug in the
recently refactored support in the `wasm-gc` crate, providing a perfect
time and motivation to start writing some tests!
All tests added here are `*.wat` files which contain the expected output
after the gc pass is executed. Tests are automatically updated with
`BLESS_TESTS=1` in the environment, which is the expected way to
generate the output for each test.
This commit updates the `wasm-gc` pass of wasm-bindgen to eliminate
duplicate types in the type section, effectively enabling a gc of the
type section itself. The main purpose here is ensure that code generated
by `wasm-bindgen` itself doesn't have to go too far out of its way to
deduplicate at generation time, but rather it can rely on the gc pass to
clean up.
Note that this currently depends on paritytech/parity-wasm#231, but this
can be updated if that ends up not landing.
This commit adds support for running a gc pass over locals in a
function. This will remove dead local declarations for a function
(completely unused) as well as compact existing entries to ensure that
we don't have two local declarations of the same type.
While this was initially intended for some future support of emitting
shims in `wasm-bindgen`, it turns out this pass is firing quite a lot
over existing functions generated by LLVM. Looks like we may see benefit
from this today with slightly smaller wasm binaries!
These don't seem to be widely used and they're not needed by
wasm-bindgen itself, so let's remove the symbols by default and
optionally in the future we can add an option to retain them.
This commit restructures some of the internals of `wasm-gc` now that
I've actually got a better grasp on the wasm format and what all the
ownership edges look like. This shouldn't actually result in any
user-facing changes, but should make us be a bit more compatible with
operations in the future.
Memories/tables/elements/segments are no longer considered automatic
roots but rather need to be rooted by something else to prevent a gc.
For example an element section is gc'd along with a table if the table
is never referenced, along with data segments as well if the memory
isn't referenced.
Additionally all index sets now don't contained offseted indices, but
rather everything is always stored relative to the "index space" to
ensure consistency.
This should make it a bit easier to add future items to gc!
Previously whenever a future readiness notification came in we would
immediately start polling a future. This ends up having two downsides,
however:
* First, the stack depth may run a risk of getting blown. There's no
recursion limit to defer execution to later, which means that if
futures are always ready we'll keep making the stack deeper.
* Second, and more worrisome in the near term, apparently future
adapaters in the `futures` crate (namely the unsync oneshot channel)
doesn't actually work if you immediately poll on readiness. This may
or may not be a bug in the `futures` crate but it's good to fix it
here anyway.
As a result whenever a future is ready to get polled again we defer its
polling to the next turn of the event loop. This should ensure that the
current call stack is always drained and we're effectively enqueueing
the future to be polled in the near future.
... and add a parallel raytracing demo!
This commit adds enough support to `wasm-bindgen` to produce a workable
wasm binary *today* with the experimental WebAssembly threads support
implemented in Firefox Nightly. I've tried to comment what's going on in
the commits and such, but at a high level the changes made here are:
* A new transformation, living in a new `wasm-bindgen-threads-xform`
crate, prepares a wasm module for parallel execution. This performs a
number of mundane tasks which I hope to detail in a blog post later on.
* The `--no-modules` output is enhanced with more support for when
shared memory is enabled, allowing passing in the module/memory to
initialize the wasm instance on multiple threads (sharing both module
and memory).
* The `wasm-bindgen` crate now offers the ability, in `--no-modules`
mode, to get a handle on the `WebAssembly.Module` instance.
* The example itself requires Xargo to recompile the standard library
with atomics and an experimental feature enabled. Afterwards it
experimentally also enables threading support in wasm-bindgen.
I've also added hopefully enough CI support to compile this example in a
builder so we can upload it and poke around live online. I hope to
detail more about the technical details here in a blog post soon as
well!
This shaves a little over 2MB off the download locally for Linux,
removing debuginfo (which no one's probably gonna use anyway) as well as
switching from jemalloc to the system allocator.
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 migrates away from using Serde for the custom section in
wasm executables. This is a refactoring of a purely-internal data
structure to `wasm-bindgen` and should have no visible functional change
on users.
The motivation for this commit is two fold:
* First, the compile times using `serde_json` and `serde_derive` for the
syntax extension isn't the most fun.
* Second, eventually we're going to want to stablize the layout of the
custom section, and it's highly unlikely to be json!
Primarily, though, the intention of this commit is to improve the
cold-cache compile time of `wasm-bindgen` by ensuring that for new users
this project builds as quickly as possible. By removing some heavyweight
dependencies from the procedural macro, `serde`, `serde_derive`, and
`serde_json`, we're able to get a pretty nice build time improvement for
the `wasm-bindgen` crate itself:
| | single-core build | parallel build |
|-------------|-------------------|----------------|
| master | 36.5s | 17.3s |
| this commit | 20.5s | 11.8s |
These are't really end-all-be-all wins but they're much better
especially on the spectrum of weaker CPUs (in theory modeled by the
single-core case showing we have 42% less CPU work in theory).
This commit fixes instantiation of the wasm module even if some of the
improted APIs don't exist. This extends the functionality initially
added in #409 to attempt to gracefully allow importing values from the
environment which don't actually exist in all contexts. In addition to
nonexistent methods being handled now entire nonexistent types are now
also handled.
I suspect that eventually we'll add a CLI flag to `wasm-bindgen` to say
"I assert everything exists, don't check it" to trim out the extra JS
glue generated here. In the meantime though this'll pave the way for a
wasm-bindgen shim to be instantiated in both a web worker and the main
thread, while using DOM-like APIs only on the main thread.
When we add threads it's not actually valid to have a global cache as
the index is only valid on one thread! Instead let's use a per-thread
cache using `thread_local!` which compiles to basically the same code as
before for single-threaded wasm.
This commit adds support for the `slice` function on all `TypedArray`
instances. The `slice` function is similar to `subarray` except that it
actually copies the data, whereas `subarray` just returns a different
view into data.
The `JsValue` type wraps a slab/heap of js objects which is managed by
the wasm-bindgen shim, and everything here is not actually able to cross
any thread boundaries. When wasm actually has threads, for example, each
thread will have to have its own slab of objects generated by
wasm-bindgen, and indices in one slab aren't valid in any other slabs.
This is technically a breaking change because `JsValue` was previously
`Send` and `Sync`, but I'm hoping that in practice this isn't actually a
breaking change because nothing in wasm can be using threads which in
theory shouldn't activate the `Send` and/or `Sync` bounds.
The bindings generation for a class would accidentally omit the `__wrap`
function if it was only discovered very late in the process that
`__wrap` was needed, after we'd already passed the point where we needed
to have decided that.
This commit moves struct field generation of bindings much earlier in
the binding generation process which should ensure everything is all
hooked up by the time we generate the classes themselves.
Closes#949
The official pathname separator on Windows is `\` instead of `/`, but
we've been unconditionally using `/`. This typically works on Windows
because Cargo's default `OUT_DIR` listing is a normal `C:\...` path
which works with either `/` or `\`. If, however, a user sets
`CARGO_TARGET_DIR` to a UNC-style path like `\\?\C:\...` then `/` is
*not* the same as `\`, but rather `/` is interpreted as part of the file
name (to allow file names with `/` in the name).
Let's bypass all this and just use a build script output env var.
Closes#943
The `wasm-bindgen` crate is effectively the only user of this crate now
that the `wasm-gc` tool has been deprecated. It's also much easier to
keep it in this repository as it's easier to sync changes to
`parity-wasm`. I'd also like to start refactoring out utilities for
managing a `parity_wasm::Module` to share between this crate and the
other CLI support code.
Adding `#[inline]` will typically improve codegen for optimized builds
without LTO (so far the majority in practice) by allowing functions that
otherwise couldn't be inlined across codegen units to get inlined
across codegen units.
Right now `wasm-bindgen` has a lot of functions that are very small and
delegate to other functions, but aren't otherwise candidates for
inlining because they're concrete.
I was poking around in release-mode wasm recently and noticed an
alarming number of functions for tiny pieces of functionality, which
motivates this patch!
This commit employs the strategy described in #908 to apply a
non-breaking change to fix WebIDL to be compatible with all browsers,
including Safari.
The problem here is that `BaseAudioContext` and `AudioScheduledSourceNode`
are not types in Safari, but they are types in Firefox/Chrome. The fix
here was to move the contents of these two interfaces into mixins, and
then include the mixins in all classes which inherit from these two
classes. That should have the same effect as defining the methods
inherently on the original interface.
Additionally a special `[RustDeprecated]` attribute to WebIDL was added
to signify interfaces this has happened to. Currently it's directly
tailored towards this case of "this intermediate class doesn't exist in
all browsers", but we may want to refine and extend the deprecation
message over time.
Although it's possible we could do this as a breaking change to
`web-sys` I'm hoping that we can do this as a non-breaking change for
now and then eventually on the next breaking release batch all these
changes together, deleting the intermediate classes. This is also
hopefully a good trial run for how stable web-sys can be when it's
actually stable!
cc #897
cc #908
This import is only used if some features get used and it is way easier to just
quiet the warning when those features aren't used than to try and `cfg` this
import.
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
This commit improves the codegen for `Closure<T>`, primarily for ZST
where the closure doesn't actually capture anything. Previously
`wasm-bindgen` would unconditionally allocate an `Rc` for a fat pointer,
meaning that it would always hit the allocator even when the `Box<T>`
didn't actually contain an allocation. Now the reference count for the
closure is stored on the JS object rather than in Rust.
Some more advanced tests were added along the way to ensure that
functionality didn't regress, and otherwise the calling convention for
`Closure` changed a good deal but should still be the same user-facing.
The primary change was that the reference count reaching zero may cause
JS to need to run the destructor. It simply returns this information in
`Drop for Closure` and otherwise when calling it now also retains a
function pointer that runs the destructor.
Closes#874
Previously the "container attribute" were set to the attributes of the
mixin itself, but we want the container attributes to be that of the
type which includes the mixin (like `Window`) as those attributes
contain information about whether or not bindings are `structural`.
The end result with this is that the `structural` tag is now used for
properties on `Window`, correctly generating setters/getters.
Closes#904
* Regenerate the list of features for the crate given recent
improvements, enabling some more types to be bound.
* Add feature gates for the `css` and `console` namespaces (modules),
gating the APIs by default. Now `web_sys` has zero APIs unless they're
requested.
* Improved the "required feature" documentation for `struct` types to
not list parent classes and mention just the `struct` type instead.
Previously the `link_mem_intrinsics` hack actually had a runtime
overhead by storing a value into a global location, but it turns out we
can actually use a non-inlined function call as part of the *descriptor*
which requires this to be in the final binary, but we'll end up snip'ing
the value at the end.
All in all this should mean that it's not a zero-overhead solution for
linking these intrinsics! The `#[wasm_bindgen]` attribute already has
other problems if the descriptors don't show up, so that's the least of
our issues!
This commit implements support for binding APIs that take
`Uint8ClampedArray` in JS. This is pretty rare but comes up in a
`web-sys` binding or two, and we're now able to bind these APIs instead
of having to omit the bindings.
The `Uint8ClampedArray` type is bound by using the `Clamped` marker
struct in Rust. For example this is declaring a JS API that takes
`Uint8ClampedArray`:
use wasm_bindgen::Clamped;
#[wasm_bindgen]
extern {
fn takes_clamped(a: Clamped<&[u8]>);
}
The `Clamped` type currently only works when wrapping the `&[u8]`, `&mut
[u8]`, and `Vec<u8>` types. Everything else will produce an error at
`wasm-bindgen` time.
Closes#421
All these functions are now provided by upstream compiler-builtins, so
there's no need for us to be binding them automatically. The remaining
`Math_*` functions are also no longer needed on nightly after
https://github.com/rust-lang/rust/pull/54257 but that PR isn't on beta,
so we'll need to leave these here for awhile while beta rides the trains
Bind them all as `JsValue` as that's the "least common ancestor" we can
work with. Fixes up one location in WebIDL where `Option<JsValue>`
arose as we haven't implemented that.
Closes#817
This commit removes the need for an injected `ConstructorToken` type and
also cleans up the story we have for generating constructors a bit.
After this commit a `constructor()` is omitted entirely if we're in
non-debug mode and there's no actual listed constructor. Additionally we
don't deal with splat arguments and rerouting constructors, Nick was
kind enough to enlighten me about `Object.create` which is creating an
instance without running the constructor!
Instances of an exported type are now created through one of two
methods:
* If `#[wasm_bindgen(constructor)]` is present, then a `constructor` is
generated with the appropriate signature. If a constructor is not
present and we're in debug mode, a throwing constructor is generated.
If we're in release mode and there's no constructor, no constructor is
generated.
* Otherwise if a binding returns an instance of a type (or otherwise
needs to manfuacture an instance, then it will cause an internal
`__wrap` function to be generated. This function will use
`Object.create` to create an instance without running the constructor.
This should ideally clean up our generated JS for classes quite a bit,
making it much more lean-and-mean!
If the setter doesn't start with `set_*` then we currently panic, but
panicking is bad! Instead let's thread through structured errors to make
sure they make their way to the top
Previously `wasm-bindgen` would take its `breaks_if_inlined` shims and
attempt to remove them entirely, replacing calls to `breaks_if_inlined`
to the imported closure factories. This worked great in that it would
remove the `breaks_if_inlined` funtion entirely, removing the "cost" of
the `#[inline(never)]`.
Unfortunately as #864 discovered this is "too clever by half". LLVM's
aggressive optimizations won't inline `breaks_if_inlined`, but it may
still change the ABI! We can't replace calls to `breaks_if_inlined` if
the signature changes, because the function its calling has a fixed signature.
This commit cops out a bit and instead of replacing calls to
`breaks_if_inlined` to the imported closure factories, we instead
rewrite calls to `__wbindgen_describe_closure` to the closure factories.
This means that the `breaks_if_inlined` shims do not get removed. It
also means that the closure factory shims have a third and final
argument (what would be the function pointer of the descriptor function)
which is dead and unused.
This should be a functional solution for now and let us iterate on a
true fix later on (if needed). For now the cost of this
`#[inline(never)]` and the extra unused argument should be quite small.
Closes#864
Did a bunch of grepping for `moz*` and searched for "moz" in rustdoc,
deleting anything that looked mozilla-specific. Now there's nothing left
with the "moz" prefix in rustdoc!
This commit is a large-ish scale reorganization of our examples. The
main goal here is to have a dedicated section of the guide for example,
and all examples will be listed there. Each example's `README` is now
just boilerplate pointing at the guide along with a blurb about how to
run it.
Some examples like `math` and `smorgasboard` have been deleted as they
didn't really serve much purpose, and others like `closures` have been
rewritten with `web-sys` instead of hand-bound bindings.
Overall it's hoped that this puts us in a good and consistent state for
our examples, with all of them being described in the guide, excerpts
are in the guide, and they're all relatively idiomatically using
`web-sys`.
This commit adds support for exporting a function defined in Rust that returns a
`Result`, translating the `Ok` variant to the actual return value and the `Err`
variant to an exception that's thrown in JS.
The support for return types and descriptors was rejiggered a bit to be a bit
more abstract and more well suited for this purpose. We no longer distinguish
between functions with a return value and those without a return value.
Additionally a new trait, `ReturnWasmAbi`, is used for converting return values.
This trait is an internal implementation detail, however, and shouldn't surface
itself to users much (if at all).
Closes#841
This is intended to address #834 where we don't actually want methods scoped
like this! Instead we'll provide one unique accessor for the `window` object
itself.
This is a roundabout way to say that this addresses the last comment on #23,
namely if you only use the `console` submodule from `web_sys` it doesn't
actually link correctly!
The problem here has to do with codegen units and the compiler. The compiler
will create a codegen unit for each `mod` in the source code. If a codegen unit
isn't actually used, then the codegen unit is removed from the final link step.
This causes problems for web-sys where the JSON description of our program was
part of the main CGU but not in each submodule, so when submodules were only
used the descriptor program in the main CGU was not included.
The fix in this commit is to instead generate a descriptor program in the
submodule itself instead of leaving it in the main CGU. By removing the `Module`
node in the AST this naturally happens as the descriptor is only generated in
the same module as all other associated items.
