Liam Murphy 88f8917efb Fix Rust values getting GC'd while still borrowed and not getting GC'd if created via. constructor (#3940)
* Add a failing test

* Force tests to run sequentially

At first I tried fixing them so that they didn't need to (giving each of them
their own `dropCount`), but running multiple GCs in parallel seems to be flaky.

* Add objects created via. constructors to the FinalizationRegistry

* Add a failing test

* Fix exported Rust types being GC'd while still borrowed

I also discovered and fixed an extra bug while working on this, which
was that `LongRefFromWasmAbi` wasn't getting used for `self`: this bug
didn't cause any problems before, because the only type that had a
different `LongRefFromWasmAbi` impl than its `RefFromWasmAbi` impl was
`JsValue` which can't be the type of `self`.

It became a problem here because I made the new `LongRefFromWasmAbi`
impl for exported Rust types clone the `Rc`, whereas the
`RefFromWasmAbi` impl doesn't because garbage collection can't occur
during the synchronous call that the value has to live for.

I might actually change it so that both of the impls behave like the
current `LongRefFromWasmAbi` impl, though: cloning an `Rc` isn't
expensive and so having the second different impl just makes things more
complicated for no good reason. I just left it in this commit as
explanation for how I discovered the `LongRefFromWasmAbi` issue.

* Unify RefFromWasmAbi and LongRefFromWasmAbi impls

* Get rid of needless looping

* Get rid of outdated `borrow_mut`

Now that borrowing a Rust value always clones its `Rc`, `Rc::into_inner`
is a sufficient check that the value isn't borrowed.

* Get rid of needless `mut`

For some reason I was getting errors before without it, but that seems
to be fixed now. (It's probably something to do with having removed the
`borrow_mut`, but that only takes `&self`, so I still don't get it.)

* Update reference tests

* Add changelog entry

* Update schema hash

* Use Rc::try_unwrap instead of Rc::into_inner

* Skip GC tests

They seem to be far flakier in CI than locally for some reason, and I
don't see any way to solve it; so just turn them off. :(

I also got rid of the weird GC warmup hack because it doesn't do
anything anymore; I could've sworn it was a reproducible effect before,
but it seems to make no difference now.
2024-06-01 22:18:14 +10:00
2024-04-18 23:57:16 +02:00
2024-03-04 11:25:46 +01:00
2017-12-18 14:45:06 -08:00
2017-12-18 14:45:06 -08:00

wasm-bindgen

Facilitating high-level interactions between Wasm modules and JavaScript.

Build Status Crates.io version Download docs.rs docs

Guide (main branch) | API Docs | Contributing | Chat

Built with 🦀🕸 by The Rust and WebAssembly Working Group

Install wasm-bindgen-cli

You can install it using cargo install:

cargo install wasm-bindgen-cli

Or, you can download it from the release page.

If you have cargo-binstall installed, then you can install the pre-built artifacts by running:

cargo binstall wasm-bindgen-cli

Example

Import JavaScript things into Rust and export Rust things to JavaScript.

use wasm_bindgen::prelude::*;

// Import the `window.alert` function from the Web.
#[wasm_bindgen]
extern "C" {
    fn alert(s: &str);
}

// Export a `greet` function from Rust to JavaScript, that alerts a
// hello message.
#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}

Use exported Rust things from JavaScript with ECMAScript modules!

import { greet } from "./hello_world";

greet("World!");

Features

  • Lightweight. Only pay for what you use. wasm-bindgen only generates bindings and glue for the JavaScript imports you actually use and Rust functionality that you export. For example, importing and using the document.querySelector method doesn't cause Node.prototype.appendChild or window.alert to be included in the bindings as well.

  • ECMAScript modules. Just import WebAssembly modules the same way you would import JavaScript modules. Future compatible with WebAssembly modules and ECMAScript modules integration.

  • Designed with the "Web IDL bindings" proposal in mind. Eventually, there won't be any JavaScript shims between Rust-generated wasm functions and native DOM methods. Because the wasm functions are statically type checked, some of those native methods' dynamic type checks should become unnecessary, promising to unlock even-faster-than-JavaScript DOM access.

Guide

📚 Read the wasm-bindgen guide here! 📚

You can find general documentation about using Rust and WebAssembly together here.

API Docs

License

This project is licensed under either of

at your option.

Contribution

See the "Contributing" section of the guide for information on hacking on wasm-bindgen!

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this project by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Description
No description provided
Readme 15 MiB
Languages
Rust 98.4%
JavaScript 1.1%
WebAssembly 0.3%
HTML 0.1%