rustwasm/wasm-bindgen
1
0
Fork 0
mirror of https://github.com/rustwasm/wasm-bindgen.git synced 2024-11-23 12:02:40 +03:00
Code Issues Actions Packages Projects Releases Wiki Activity

Consistently capitalize “Wasm” (#4094)

Browse Source
This commit is contained in:
Martin Geisler 2024-08-27 10:18:49 +02:00 committed by GitHub
parent 125aa23b58
commit e4f8c4540a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
78 changed files with 259 additions and 259 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
CHANGELOG.md
View File

@ -472,7 +472,7 @@ Released 2023-11-01
[#3537](https://github.com/rustwasm/wasm-bindgen/pull/3537)
* Changed behavior when compiling to `wasm32-wasi` to match `wasm32-emscripten` and
non-WASM targets, generating a stub that panics when called rather than a wasm-
non-Wasm targets, generating a stub that panics when called rather than a wasm-
bindgen placeholder.
[#3233](https://github.com/rustwasm/wasm-bindgen/pull/3233)
@ -940,7 +940,7 @@ Released 2020-04-29.
[#2099](https://github.com/rustwasm/wasm-bindgen/pull/2099)
* The output of `wasm-bindgen` is now compatible with Webpack 5 and the updated
version of the wasm ESM integration specification.
version of the Wasm ESM integration specification.
[#2110](https://github.com/rustwasm/wasm-bindgen/pull/2099)
--------------------------------------------------------------------------------
@ -1123,7 +1123,7 @@ Released 2019-11-19.
* Running `wasm-bindgen` over empty anyref modules now works again.
[#1861](https://github.com/rustwasm/wasm-bindgen/pull/1861)
* Support for multi-value JS engines has been fixed as a wasm interface types
* Support for multi-value JS engines has been fixed as a Wasm interface types
polyfill.
[#1863](https://github.com/rustwasm/wasm-bindgen/pull/1863)
@ -1346,8 +1346,8 @@ Released 2019-07-11.
slices.
[#1639](https://github.com/rustwasm/wasm-bindgen/pull/1639)
* When using the `bundler` target the import of the wasm file now uses the
`.wasm` extension to ensure a wasm file is loaded.
* When using the `bundler` target the import of the Wasm file now uses the
`.wasm` extension to ensure a Wasm file is loaded.
[#1646](https://github.com/rustwasm/wasm-bindgen/pull/1646)
* The old internal `Stack` trait has been removed since it is no longer used.
@ -1475,7 +1475,7 @@ Released 2019-05-16.
* A utility for counting the size of the `anyref` heap has been added.
[#1521](https://github.com/rustwasm/wasm-bindgen/pull/1521)
* Passing ASCII-only strings to WASM should now be significantly faster.
* Passing ASCII-only strings to Wasm should now be significantly faster.
[#1470](https://github.com/rustwasm/wasm-bindgen/pull/1470)
* The `selectionStart` and `selectionEnd` APIs of text areas have been enabled.
@ -1615,7 +1615,7 @@ Released 2019-04-10.
[#1416](https://github.com/rustwasm/wasm-bindgen/pull/1416)
* A `wasm_bindgen::function_table()` function has been added to expose the
`WebAssembly.Table` and get access to it in wasm code.
`WebAssembly.Table` and get access to it in Wasm code.
[#1431](https://github.com/rustwasm/wasm-bindgen/pull/1431)
### Fixed
@ -1778,7 +1778,7 @@ Released 2019-02-15.
[#1225](https://github.com/rustwasm/wasm-bindgen/pull/1225).
* A `--remove-producers-section` flag has been added to the CLI tool to, well,
remove the `producers` section from the final wasm file.
remove the `producers` section from the final Wasm file.
[#1256](https://github.com/rustwasm/wasm-bindgen/pull/1256).
### Fixed
@ -1816,7 +1816,7 @@ Released 2019-02-12.
### Changed
* `wasm-bindgen` now internally uses the `walrus` crate to perform its
transformations of the wasm that rustc/LLVM emits. See
transformations of the Wasm that rustc/LLVM emits. See
[#1237](https://github.com/rustwasm/wasm-bindgen/pull/1237).
### Fixed
@ -1968,17 +1968,17 @@ Released 2018-12-04.
### Added
* Add a `#[wasm_bindgen(start)]` attribute to customize the `start` section of
the wasm module.
the Wasm module.
[#1057](https://github.com/rustwasm/wasm-bindgen/pull/1057)
* Add support for producing the new "producers" section of wasm binaries
* Add support for producing the new "producers" section of Wasm binaries
[#1041](https://github.com/rustwasm/wasm-bindgen/pull/1041)
* Add support a `typescript_custom_section` attribute for producing custom
typescript abstractions
[#1048](https://github.com/rustwasm/wasm-bindgen/pull/1048)
* Generate `*.d.ts` files for wasm files in addition to the JS bindings
* Generate `*.d.ts` files for Wasm files in addition to the JS bindings
[#1053](https://github.com/rustwasm/wasm-bindgen/pull/1053)
* Add a feature to assert that all attributes in `#[wasm_bindgen]` are used to
@ -2255,7 +2255,7 @@ Released 2018-09-07
### Fixed
* The "names" section of the wasm binary is now correctly preserved by
* The "names" section of the Wasm binary is now correctly preserved by
wasm-bindgen.
--------------------------------------------------------------------------------

2
README.md
View File

@ -87,7 +87,7 @@ greet("World!");
* **Designed with the ["Web IDL bindings" proposal][webidl-bindings] 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
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.

6
benchmarks/index.html
View File

@ -56,7 +56,7 @@ table td {
<p class='about'>
This benchmarks tests out how long it take JS to call a thunk in
the given language. For example JS will call a JS thunk or
JS will call a wasm function that does nothing.
JS will call a Wasm function that does nothing.
</p>
</td>
@ -131,7 +131,7 @@ table td {
<p class='about'>
This benchmarks calculates the 40th fibonacci number. It in
theory should favor wasm since wasm is "better a compute", but
theory should favor Wasm since Wasm is "better a compute", but
a good JIT will probably make the code roughly equivalent.
</p>
</td>
@ -296,7 +296,7 @@ table td {
<a class='about-open' href='#'>(?)</a>
<p class='about'>
This benchmarks the overhead of passing strings to wasm and
This benchmarks the overhead of passing strings to Wasm and
also receiving them from wasm.
</p>
</td>

2
benchmarks/index.js
View File

@ -160,7 +160,7 @@ function executeBenchmark(name, bm) {
});
}
// Load wasm files and when they're done (plus the DOM) then we initialize
// Load Wasm files and when they're done (plus the DOM) then we initialize
// everything
const wasms = [];
wasms.push(wbindgen_init('./pkg/wasm_bindgen_benchmark_bg.wasm'));

4
crates/backend/src/ast.rs
View File

@ -1,5 +1,5 @@
//! A representation of the Abstract Syntax Tree of a Rust program,
//! with all the added metadata necessary to generate WASM bindings
//! with all the added metadata necessary to generate Wasm bindings
//! for it.
use crate::{util::ShortHash, Diagnostic};
@ -100,7 +100,7 @@ pub struct Export {
pub rust_class: Option<Ident>,
/// The name of the rust function/method on the rust side.
pub rust_name: Ident,
/// Whether or not this function should be flagged as the wasm start
/// Whether or not this function should be flagged as the Wasm start
/// function.
pub start: bool,
/// Path to wasm_bindgen

6
crates/backend/src/codegen.rs
View File

@ -86,7 +86,7 @@ impl TryToTokens for ast::Program {
Diagnostic::from_vec(errors)?;
// Generate a static which will eventually be what lives in a custom section
// of the wasm executable. For now it's just a plain old static, but we'll
// of the Wasm executable. For now it's just a plain old static, but we'll
// eventually have it actually in its own section.
// See comments in `crates/cli-support/src/lib.rs` about what this
@ -278,7 +278,7 @@ impl ToTokens for ast::Struct {
#[cfg(not(all(target_arch = "wasm32", target_os = "unknown")))]
unsafe fn #new_fn(_: u32) -> u32 {
panic!("cannot convert to JsValue outside of the wasm target")
panic!("cannot convert to JsValue outside of the Wasm target")
}
unsafe {
@ -384,7 +384,7 @@ impl ToTokens for ast::Struct {
#[cfg(not(all(target_arch = "wasm32", target_os = "unknown")))]
unsafe fn #unwrap_fn(_: u32) -> u32 {
panic!("cannot convert from JsValue outside of the wasm target")
panic!("cannot convert from JsValue outside of the Wasm target")
}
let ptr = unsafe { #unwrap_fn(idx) };

10
crates/cli-support/src/externref.rs
View File

@ -86,7 +86,7 @@ pub fn process(module: &mut Module) -> Result<()> {
for instr in instrs {
match instr.instr {
// Calls to the heap live count intrinsic are now routed to the
// actual wasm function which keeps track of this.
// actual Wasm function which keeps track of this.
Instruction::CallAdapter(adapter) => {
let id = match meta.live_count {
Some(id) => id,
@ -103,7 +103,7 @@ pub fn process(module: &mut Module) -> Result<()> {
instr.instr = Instruction::CallCore(id);
}
// Optional externref values are now managed in the wasm module, so
// Optional externref values are now managed in the Wasm module, so
// we need to store where they're managed.
Instruction::I32FromOptionExternref {
ref mut table_and_alloc,
@ -333,7 +333,7 @@ fn export_xform(cx: &mut Context, export: Export, instrs: &mut Vec<InstructionDa
}
// Delete all unnecessary externref management instructions. We're going to
// sink these instructions into the wasm module itself.
// sink these instructions into the Wasm module itself.
for idx in to_delete.into_iter().rev() {
instrs.remove(idx);
}
@ -344,7 +344,7 @@ fn module_needs_externref_metadata(aux: &WasmBindgenAux, section: &NonstandardWi
use Instruction::*;
// our `handleError` intrinsic uses a few pieces of metadata to store
// indices directly into the wasm module.
// indices directly into the Wasm module.
if !aux.imports_with_catch.is_empty() {
return true;
}
@ -387,7 +387,7 @@ fn module_needs_externref_metadata(aux: &WasmBindgenAux, section: &NonstandardWi
})
}
/// In MVP wasm all element segments must be contiguous lists of function
/// In MVP Wasm all element segments must be contiguous lists of function
/// indices. Post-MVP with reference types element segments can have holes.
/// While `walrus` will select the encoding that fits, this function forces the
/// listing of segments to be MVP-compatible.

8
crates/cli-support/src/js/binding.rs
View File

@ -54,7 +54,7 @@ pub struct JsBuilder<'a, 'b> {
/// use to translate the `arg.get` instruction.
args: Vec<String>,
/// The wasm interface types "stack". The expressions pushed onto this stack
/// The Wasm interface types "stack". The expressions pushed onto this stack
/// are intended to be *pure*, and if they're not, they should be pushed
/// into the `prelude`, assigned to a variable, and the variable should be
/// pushed to the stack. We're not super principled about this though, so
@ -164,7 +164,7 @@ impl<'a, 'b> Builder<'a, 'b> {
// We don't actually manage a literal stack at runtime, but instead we
// act as more of a compiler to generate straight-line code to make it
// more JIT-friendly. The generated code should be equivalent to the
// wasm interface types stack machine, however.
// Wasm interface types stack machine, however.
for instr in instructions {
instruction(
&mut js,
@ -1103,8 +1103,8 @@ fn instruction(
// Then pass it the pointer and the length of where we copied it.
js.push(format!("ptr{}", i));
js.push(format!("len{}", i));
// Then we give wasm a reference to the original typed array, so that it can
// update it with modifications made on the wasm side before returning.
// Then we give Wasm a reference to the original typed array, so that it can
// update it with modifications made on the Wasm side before returning.
js.push(val);
}

34
crates/cli-support/src/js/mod.rs
View File

@ -36,7 +36,7 @@ pub struct Context<'a> {
/// renames for each identifier.
js_imports: HashMap<String, Vec<(String, Option<String>)>>,
/// A map of each wasm import and what JS to hook up to it.
/// A map of each Wasm import and what JS to hook up to it.
wasm_import_definitions: HashMap<ImportId, String>,
/// A map from an import to the name we've locally imported it as.
@ -377,7 +377,7 @@ impl<'a> Context<'a> {
}
// Depending on the output mode, generate necessary glue to actually
// import the wasm file in one way or another.
// import the Wasm file in one way or another.
let mut init = (String::new(), String::new());
let mut footer = String::new();
let mut imports = self.js_import_header()?;
@ -445,9 +445,9 @@ impl<'a> Context<'a> {
}
}
// With Bundlers we can simply import the wasm file as if it were an ES module
// With Bundlers we can simply import the Wasm file as if it were an ES module
// and let the bundler/runtime take care of it.
// With Node we manually read the wasm file from the filesystem and instantiate it.
// With Node we manually read the Wasm file from the filesystem and instantiate it.
OutputMode::Bundler { .. } | OutputMode::Node { module: true } => {
for (id, js) in crate::sorted_iter(&self.wasm_import_definitions) {
let import = self.module.imports.get_mut(*id);
@ -491,7 +491,7 @@ impl<'a> Context<'a> {
}
// With a browser-native output we're generating an ES module, but
// browsers don't support natively importing wasm right now so we
// browsers don't support natively importing Wasm right now so we
// expose the same initialization function as `--target no-modules`
// as the default export of the module.
OutputMode::Web => {
@ -821,7 +821,7 @@ impl<'a> Context<'a> {
}} catch (e) {{
if (module.headers.get('Content-Type') != 'application/wasm') {{
console.warn(\"`WebAssembly.instantiateStreaming` failed \
because your server does not serve wasm with \
because your server does not serve Wasm with \
`application/wasm` MIME type. Falling back to \
`WebAssembly.instantiate` which is slower. Original \
error:\\n\", e);
@ -1307,7 +1307,7 @@ impl<'a> Context<'a> {
}
}
// A fast path that directly writes char codes into WASM memory as long
// A fast path that directly writes char codes into Wasm memory as long
// as it finds only ASCII characters.
//
// This is much faster for common ASCII strings because it can avoid
@ -1836,7 +1836,7 @@ impl<'a> Context<'a> {
let cache = format!("cached{}Memory{}", kind, view.num);
let resized_check = if self.module.memories.get(memory).shared {
// When it's backed by a `SharedArrayBuffer`, growing the wasm module's memory
// When it's backed by a `SharedArrayBuffer`, growing the Wasm module's memory
// doesn't detach old references; instead, it just leaves them pointing to a
// slice of the up-to-date memory. So in order to check if it's been grown, we
// have to compare it to the up-to-date buffer.
@ -2393,7 +2393,7 @@ impl<'a> Context<'a> {
}
/// If a start function is present, it removes it from the `start` section
/// of the wasm module and then moves it to an exported function, named
/// of the Wasm module and then moves it to an exported function, named
/// `__wbindgen_start`.
fn unstart_start_function(&mut self) -> bool {
let start = match self.module.start.take() {
@ -2780,7 +2780,7 @@ impl<'a> Context<'a> {
}
}
/// Attempts to directly hook up the `id` import in the wasm module with
/// Attempts to directly hook up the `id` import in the Wasm module with
/// the `instrs` specified.
///
/// If this succeeds it returns `Ok(true)`, otherwise if it cannot be
@ -2845,15 +2845,15 @@ impl<'a> Context<'a> {
// If there's no field projection happening here and this is a direct
// import from an ES-looking module, then we can actually just hook this
// up directly in the wasm file itself. Note that this is covered in the
// up directly in the Wasm file itself. Note that this is covered in the
// various output formats as well:
//
// * `bundler` - they think wasm is an ES module anyway
// * `bundler` - they think Wasm is an ES module anyway
// * `web` - we're sure to emit more `import` directives during
// `gen_init` and we update the import object accordingly.
// * `nodejs` - the polyfill we have for requiring a wasm file as a node
// * `nodejs` - the polyfill we have for requiring a Wasm file as a node
// module will naturally emit `require` directives for the module
// listed on each wasm import.
// listed on each Wasm import.
// * `no-modules` - imports aren't allowed here anyway from other
// modules and an error is generated.
if js.fields.is_empty() {
@ -2928,11 +2928,11 @@ impl<'a> Context<'a> {
// needed.
CallAdapter(_) => saw_call = true,
// Conversions to wasm integers are always supported since
// Conversions to Wasm integers are always supported since
// they're coerced into i32/f32/f64 appropriately.
IntToWasm { .. } => {}
// Converts from wasm to JS, however, only supports most
// Converts from Wasm to JS, however, only supports most
// integers. Converting into a u32 isn't supported because we
// need to generate glue to change the sign.
WasmToInt {
@ -3993,7 +3993,7 @@ impl<'a> Context<'a> {
let stack_pointer = match self.aux.stack_pointer {
Some(s) => s,
// In theory this shouldn't happen since malloc is included in
// most wasm binaries (and may be gc'd out) and that almost
// most Wasm binaries (and may be gc'd out) and that almost
// always pulls in a stack pointer. We can try to synthesize
// something here later if necessary.
None => bail!("failed to find stack pointer"),

10
crates/cli-support/src/lib.rs
View File

@ -35,7 +35,7 @@ pub struct Bindgen {
remove_producers_section: bool,
omit_default_module_path: bool,
emit_start: bool,
// Support for the wasm threads proposal, transforms the wasm module to be
// Support for the Wasm threads proposal, transforms the Wasm module to be
// "ready to be instantiated on any thread"
threads: wasm_bindgen_threads_xform::Config,
externref: bool,
@ -364,7 +364,7 @@ impl Bindgen {
descriptors::execute(&mut module)?;
// Process the custom section we extracted earlier. In its stead insert
// a forward-compatible wasm interface types section as well as an
// a forward-compatible Wasm interface types section as well as an
// auxiliary section for all sorts of miscellaneous information and
// features #[wasm_bindgen] supports that aren't covered by wasm
// interface types.
@ -405,7 +405,7 @@ impl Bindgen {
.context("failed to transform return pointers into multi-value Wasm")?;
}
// We've done a whole bunch of transformations to the wasm module, many
// We've done a whole bunch of transformations to the Wasm module, many
// of which leave "garbage" lying around, so let's prune out all our
// unnecessary things here.
gc_module_and_adapters(&mut module);
@ -724,8 +724,8 @@ export * from \"./{js_name}\";
fn gc_module_and_adapters(module: &mut Module) {
loop {
// Fist up, cleanup the native wasm module. Note that roots can come
// from custom sections, namely our wasm interface types custom section
// Fist up, cleanup the native Wasm module. Note that roots can come
// from custom sections, namely our Wasm interface types custom section
// as well as the aux section.
walrus::passes::gc::run(module);

2
crates/cli-support/src/multivalue.rs
View File

@ -30,7 +30,7 @@ pub fn run(module: &mut Module) -> Result<(), Error> {
.get_typed::<WasmBindgenAux>()
.expect("aux section should be present")
.stack_pointer
.ok_or_else(|| anyhow!("failed to find stack pointer in wasm module"))?;
.ok_or_else(|| anyhow!("failed to find stack pointer in Wasm module"))?;
let memory = wasm_conventions::get_memory(module)?;
let wrappers = multi_value_xform::run(module, memory, stack_pointer, &to_xform)?;

2
crates/cli-support/src/wasm2es6js.rs
View File

@ -205,7 +205,7 @@ impl Output {
// This ends up helping out in situations such as:
//
// * The start function calls an imported function
// * That imported function in turn tries to access the wasm module
// * That imported function in turn tries to access the Wasm module
//
// If we don't do this then the second step won't work because the start
// function is automatically executed before the promise of

6
crates/cli-support/src/wit/incoming.rs
View File

@ -1,8 +1,8 @@
//! Definition of how to convert Rust types (`Description`) into wasm types
//! Definition of how to convert Rust types (`Description`) into Wasm types
//! through adapter functions.
//!
//! Note that many Rust types use "nonstandard" instructions which only work in
//! the JS output, not for the "pure wasm interface types" output.
//! the JS output, not for the "pure Wasm interface types" output.
//!
//! Note that the mirror operation, going from WebAssembly to JS, is found in
//! the `outgoing.rs` module.
@ -23,7 +23,7 @@ impl InstructionBuilder<'_, '_> {
}
// This is a wrapper around `_incoming` to have a number of sanity checks
// that we don't forget things. We should always produce at least one
// wasm arge and exactly one webidl arg. Additionally the number of
// Wasm arge and exactly one webidl arg. Additionally the number of
// bindings should always match the number of webidl types for now.
let input_before = self.input.len();
let output_before = self.output.len();

28
crates/cli-support/src/wit/mod.rs
View File

@ -23,9 +23,9 @@ struct Context<'a> {
module: &'a mut Module,
adapters: NonstandardWitSection,
aux: WasmBindgenAux,
/// All of the wasm module's exported functions.
/// All of the Wasm module's exported functions.
function_exports: HashMap<String, (ExportId, FunctionId)>,
/// All of the wasm module's imported functions.
/// All of the Wasm module's imported functions.
function_imports: HashMap<String, (ImportId, FunctionId)>,
/// A map from the signature of a function in the function table to its adapter, if we've already created it.
table_adapters: HashMap<Function, AdapterId>,
@ -1093,7 +1093,7 @@ impl<'a> Context<'a> {
/// Perform a small verification pass over the module to perform some
/// internal sanity checks.
fn verify(&self) -> Result<(), Error> {
// First up verify that all imports in the wasm module from our
// First up verify that all imports in the Wasm module from our
// `$PLACEHOLDER_MODULE` are connected to an adapter via the
// `implements` section.
let mut implemented = HashMap::new();
@ -1182,7 +1182,7 @@ impl<'a> Context<'a> {
};
// Process the returned type first to see if it needs an out-pointer. This
// happens if the results of the incoming arguments translated to wasm take
// happens if the results of the incoming arguments translated to Wasm take
// up more than one type.
let mut ret = self.instruction_builder(true);
ret.incoming(&signature.ret)?;
@ -1200,7 +1200,7 @@ impl<'a> Context<'a> {
}
// Build up the list of instructions for our adapter function. We start out
// with all the outgoing instructions which convert all wasm params to the
// with all the outgoing instructions which convert all Wasm params to the
// desired types to call our import...
let mut instructions = args.instructions;
@ -1226,7 +1226,7 @@ impl<'a> Context<'a> {
instructions.extend(ret.instructions);
// ... and if a return pointer is in use then we need to store the types on
// the stack into the wasm return pointer. Note that we iterate in reverse
// the stack into the Wasm return pointer. Note that we iterate in reverse
// here because the last result is the top value on the stack.
let results = if uses_retptr {
let mem = args.cx.memory()?;
@ -1342,10 +1342,10 @@ impl<'a> Context<'a> {
let uses_retptr = ret.input.len() > 1;
// Our instruction stream starts out with the return pointer as the first
// argument to the wasm function, if one is in use. Then we convert
// everything to wasm types.
// argument to the Wasm function, if one is in use. Then we convert
// everything to Wasm types.
//
// After calling the core wasm function we need to load all the return
// After calling the core Wasm function we need to load all the return
// pointer arguments if there were any, otherwise we simply convert
// everything into the outgoing arguments.
let mut instructions = Vec::new();
@ -1530,7 +1530,7 @@ pub fn extract_programs<'a>(
while let Some(raw) = module.customs.remove_raw("__wasm_bindgen_unstable") {
log::debug!(
"custom section '{}' looks like a wasm bindgen section",
"custom section '{}' looks like a Wasm bindgen section",
raw.name
);
program_storage.push(raw.data);
@ -1542,7 +1542,7 @@ pub fn extract_programs<'a>(
while let Some(data) = get_remaining(&mut payload) {
// Historical versions of wasm-bindgen have used JSON as the custom
// data section format. Newer versions, however, are using a custom
// serialization protocol that looks much more like the wasm spec.
// serialization protocol that looks much more like the Wasm spec.
//
// We, however, want a sanity check to ensure that if we're running
// against the wrong wasm-bindgen we get a nicer error than an
@ -1559,10 +1559,10 @@ pub fn extract_programs<'a>(
bail!(
"
it looks like the Rust project used to create this wasm file was linked against
it looks like the Rust project used to create this Wasm file was linked against
version of wasm-bindgen that uses a different bindgen format than this binary:
rust wasm file schema version: {their_version}
rust Wasm file schema version: {their_version}
this binary schema version: {my_version}
Currently the bindgen format is unstable enough that these two schema versions
@ -1573,7 +1573,7 @@ You should be able to update the wasm-bindgen dependency with:
cargo update -p wasm-bindgen --precise {my_version}
don't forget to recompile your wasm file! Alternatively, you can update the
don't forget to recompile your Wasm file! Alternatively, you can update the
binary with:
cargo install -f wasm-bindgen-cli --version {their_version}

12
crates/cli-support/src/wit/nonstandard.rs
View File

@ -85,17 +85,17 @@ pub struct AuxExport {
pub variadic: bool,
}
/// All possible kinds of exports from a wasm module.
/// All possible kinds of exports from a Wasm module.
///
/// This `enum` says where to place an exported wasm function. For example it
/// This `enum` says where to place an exported Wasm function. For example it
/// may want to get hooked up to a JS class, or it may want to be exported as a
/// free function (etc).
///
/// TODO: it feels like this should not really be here per se. We probably want
/// to either construct the JS object itself from within wasm or somehow move
/// to either construct the JS object itself from within Wasm or somehow move
/// more of this information into some other section. Really what this is is
/// sort of an "export map" saying how to wire up all the free functions from
/// the wasm module into the output expected JS module. All our functions here
/// the Wasm module into the output expected JS module. All our functions here
/// currently take integer parameters and require a JS wrapper, but ideally
/// we'd change them one day to taking/receiving `externref` which then use some
/// sort of webidl import to customize behavior or something like that. In any
@ -184,7 +184,7 @@ pub struct AuxStruct {
pub generate_typescript: bool,
}
/// All possible types of imports that can be imported by a wasm module.
/// All possible types of imports that can be imported by a Wasm module.
///
/// This `enum` is intended to map out what an imported value is. For example
/// this contains a ton of shims and various ways you can call a function. The
@ -193,7 +193,7 @@ pub struct AuxStruct {
///
/// Note that this is *not* the same as the webidl bindings section. This is
/// intended to be coupled with that to map out what actually gets hooked up to
/// an import in the wasm module. The two work in tandem.
/// an import in the Wasm module. The two work in tandem.
///
/// Some of these items here are native to JS (like `Value`, indexing
/// operations, etc). Others are shims generated by wasm-bindgen (like `Closure`

6
crates/cli-support/src/wit/outgoing.rs
View File

@ -6,10 +6,10 @@ use walrus::ValType;
impl InstructionBuilder<'_, '_> {
/// Processes one more `Descriptor` as an argument to a JS function that
/// wasm is calling.
/// Wasm is calling.
///
/// This will internally skip `Unit` and otherwise build up the `bindings`
/// map and ensure that it's correctly mapped from wasm to JS.
/// map and ensure that it's correctly mapped from Wasm to JS.
pub fn outgoing(&mut self, arg: &Descriptor) -> Result<(), Error> {
if let Descriptor::Unit = arg {
return Ok(());
@ -213,7 +213,7 @@ impl InstructionBuilder<'_, '_> {
Descriptor::Function(descriptor) => {
// synthesize the a/b arguments that aren't present in the
// signature from wasm-bindgen but are present in the wasm file.
// signature from wasm-bindgen but are present in the Wasm file.
let mut descriptor = (**descriptor).clone();
let nargs = descriptor.arguments.len();
descriptor.arguments.insert(0, Descriptor::I32);

18
crates/cli-support/src/wit/section.rs
View File

@ -1,20 +1,20 @@
//! Support for generating a standard wasm interface types
//! Support for generating a standard Wasm interface types
//!
//! This module has all the necessary support for generating a full-fledged
//! standard wasm interface types section as defined by the `wit_walrus`
//! standard Wasm interface types section as defined by the `wit_walrus`
//! crate. This module also critically assumes that the WebAssembly module
//! being generated **must be standalone**. In this mode all sorts of features
//! supported by `#[wasm_bindgen]` aren't actually supported, such as closures,
//! imports of global js names, js getters/setters, exporting structs, etc.
//! These features may all eventually come to the standard bindings proposal,
//! but it will likely take some time. In the meantime this module simply focuses
//! on taking what's already a valid wasm module and letting it through with a
//! on taking what's already a valid Wasm module and letting it through with a
//! standard WebIDL custom section. All other modules generate an error during
//! this binding process.
//!
//! Note that when this function is called and used we're also not actually
//! generating any JS glue. Any JS glue currently generated is also invalid if
//! the module contains the wasm bindings section and it's actually respected.
//! the module contains the Wasm bindings section and it's actually respected.
use crate::wit::AuxExport;
use crate::wit::{AdapterId, AdapterJsImportKind, AdapterType, AuxExportedMethodKind, Instruction};
@ -145,7 +145,7 @@ pub fn add(module: &mut Module) -> Result<(), Error> {
bail!(
"generating a bindings section is currently incompatible with \
local JS modules being specified as well, `{}` cannot be used \
since a standalone wasm file is being generated",
since a standalone Wasm file is being generated",
name,
);
}
@ -154,7 +154,7 @@ pub fn add(module: &mut Module) -> Result<(), Error> {
bail!(
"generating a bindings section is currently incompatible with \
local JS snippets being specified as well, `{}` cannot be used \
since a standalone wasm file is being generated",
since a standalone Wasm file is being generated",
name,
);
}
@ -163,7 +163,7 @@ pub fn add(module: &mut Module) -> Result<(), Error> {
bail!(
"generating a bindings section is currently incompatible with \
package.json being consumed as well, `{}` cannot be used \
since a standalone wasm file is being generated",
since a standalone Wasm file is being generated",
path.display(),
);
}
@ -187,7 +187,7 @@ pub fn add(module: &mut Module) -> Result<(), Error> {
if let Some(enum_) = enums.iter().next() {
bail!(
"generating a bindings section is currently incompatible with \
exporting an `enum` from the wasm file, cannot export `{}`",
exporting an `enum` from the Wasm file, cannot export `{}`",
enum_.name,
);
}
@ -195,7 +195,7 @@ pub fn add(module: &mut Module) -> Result<(), Error> {
if let Some(struct_) = structs.iter().next() {
bail!(
"generating a bindings section is currently incompatible with \
exporting a `struct` from the wasm file, cannot export `{}`",
exporting a `struct` from the Wasm file, cannot export `{}`",
struct_.name,
);
}

12
crates/cli-support/src/wit/standard.rs
View File

@ -9,7 +9,7 @@ pub struct NonstandardWitSection {
/// A list of adapter functions, keyed by their id.
pub adapters: HashMap<AdapterId, Adapter>,
/// A list of pairs for adapter functions that implement core wasm imports.
/// A list of pairs for adapter functions that implement core Wasm imports.
pub implements: Vec<(ImportId, FunctionId, AdapterId)>,
/// A list of adapter functions and the names they're exported under.
@ -130,18 +130,18 @@ pub enum Instruction {
size: u32,
},
/// Pops a typed integer (`u8`, `s16`, etc.) and pushes a plain wasm `i32` or `i64` equivalent.
/// Pops a typed integer (`u8`, `s16`, etc.) and pushes a plain Wasm `i32` or `i64` equivalent.
IntToWasm {
input: AdapterType,
output: walrus::ValType,
},
/// Pops a wasm `i32` or `i64` and pushes a typed integer (`u8`, `s16`, etc.) equivalent.
/// Pops a Wasm `i32` or `i64` and pushes a typed integer (`u8`, `s16`, etc.) equivalent.
WasmToInt {
input: walrus::ValType,
output: AdapterType,
},
/// Pops a wasm `i32` and pushes the enum variant as a string
/// Pops a Wasm `i32` and pushes the enum variant as a string
WasmToStringEnum {
variant_values: Vec<String>,
},
@ -170,7 +170,7 @@ pub enum Instruction {
/// Pops an `externref` from the stack, allocates space in the externref table,
/// returns the index it was stored at.
I32FromExternrefOwned,
/// Pops an `externref` from the stack, pushes it onto the externref wasm table
/// Pops an `externref` from the stack, pushes it onto the externref Wasm table
/// stack, and returns the index it was stored at.
I32FromExternrefBorrow,
/// Pops an `externref` from the stack, assumes it's a Rust class given, and
@ -190,7 +190,7 @@ pub enum Instruction {
class: String,
},
/// Pops an `externref` from the stack, pushes either 0 if it's "none" or and
/// index into the owned wasm table it was stored at if it's "some"
/// index into the owned Wasm table it was stored at if it's "some"
I32FromOptionExternref {
/// Set to `Some` by the externref pass of where to put it in the wasm
/// module, otherwise it's shoved into the JS shim.

14
crates/cli/src/bin/wasm-bindgen-test-runner/main.rs
View File

@ -1,7 +1,7 @@
//! A "wrapper binary" used to execute wasm files as tests
//! A "wrapper binary" used to execute Wasm files as tests
//!
//! This binary is intended to be used as a "test runner" for wasm binaries,
//! being compatible with `cargo test` for the wasm target. It will
//! This binary is intended to be used as a "test runner" for Wasm binaries,
//! being compatible with `cargo test` for the Wasm target. It will
//! automatically execute `wasm-bindgen` (or the equivalent thereof) and then
//! execute either Node.js over the tests or start a server which a browser can
//! be used to run against to execute tests. In a browser mode if `CI` is in the
@ -72,7 +72,7 @@ fn main() -> anyhow::Result<()> {
let shell = shell::Shell::new();
// Currently no flags are supported, and assume there's only one argument
// which is the wasm file to test. This'll want to improve over time!
// which is the Wasm file to test. This'll want to improve over time!
let wasm_file_to_test = match args.next() {
Some(file) => PathBuf::from(file),
None => bail!("must have a file to test as first argument"),
@ -112,9 +112,9 @@ fn main() -> anyhow::Result<()> {
// Collect all tests that the test harness is supposed to run. We assume
// that any exported function with the prefix `__wbg_test` is a test we need
// to execute.
let wasm = fs::read(&wasm_file_to_test).context("failed to read wasm file")?;
let wasm = fs::read(&wasm_file_to_test).context("failed to read Wasm file")?;
let mut wasm =
walrus::Module::from_buffer(&wasm).context("failed to deserialize wasm module")?;
walrus::Module::from_buffer(&wasm).context("failed to deserialize Wasm module")?;
let mut tests = Vec::new();
for export in wasm.exports.iter() {
@ -230,7 +230,7 @@ fn main() -> anyhow::Result<()> {
.keep_debug(false)
.emit_start(false)
.generate(&tmpdir)
.context("executing `wasm-bindgen` over the wasm file")?;
.context("executing `wasm-bindgen` over the Wasm file")?;
shell.clear();
let args: Vec<_> = args.collect();

2
crates/cli/src/bin/wasm-bindgen-test-runner/node.rs
View File

@ -82,7 +82,7 @@ pub fn execute(
);
// Note that we're collecting *JS objects* that represent the functions to
// execute, and then those objects are passed into wasm for it to execute
// execute, and then those objects are passed into Wasm for it to execute
// when it sees fit.
for test in tests {
js_to_execute.push_str(&format!("tests.push('{}')\n", test));

8
crates/cli/src/bin/wasm-bindgen-test-runner/server.rs
View File

@ -167,8 +167,8 @@ pub(crate) fn spawn(
r#"
// Now that we've gotten to the point where JS is executing, update our
// status text as at this point we should be asynchronously fetching the
// wasm module.
document.getElementById('output').textContent = "Loading wasm module...";
// Wasm module.
document.getElementById('output').textContent = "Loading Wasm module...";
{}
port.addEventListener("message", function(e) {{
@ -252,8 +252,8 @@ pub(crate) fn spawn(
r#"
// Now that we've gotten to the point where JS is executing, update our
// status text as at this point we should be asynchronously fetching the
// wasm module.
document.getElementById('output').textContent = "Loading wasm module...";
// Wasm module.
document.getElementById('output').textContent = "Loading Wasm module...";
async function main(test) {{
const wasm = await init('./{0}_bg.wasm');

4
crates/cli/src/bin/wasm-bindgen.rs
View File

@ -6,7 +6,7 @@ use std::process;
use wasm_bindgen_cli_support::{Bindgen, EncodeInto};
const USAGE: &str = "
Generating JS bindings for a wasm file
Generating JS bindings for a Wasm file
Usage:
wasm-bindgen [options] <input>
@ -28,7 +28,7 @@ Options:
--debug Include otherwise-extraneous debug checks in output
--no-demangle Don't demangle Rust symbol names
--keep-lld-exports Keep exports synthesized by LLD
--keep-debug Keep debug sections in wasm files
--keep-debug Keep debug sections in Wasm files
--remove-name-section Remove the debugging `name` section of the file
--remove-producers-section Remove the telemetry `producers` section
--omit-default-module-path Don't add WebAssembly fallback imports in generated JavaScript

4
crates/cli/src/bin/wasm2es6js.rs
View File

@ -5,7 +5,7 @@ use std::fs;
use std::path::PathBuf;
const USAGE: &str = "
Converts a wasm file to an ES6 JS module
Converts a Wasm file to an ES6 JS module
Usage:
wasm2es6js [options] <input>
@ -16,7 +16,7 @@ Options:
-o --output FILE File to place output in
--out-dir DIR Directory to place output in
--typescript Output a `*.d.ts` file next to the JS output
--base64 Inline the wasm module using base64 encoding
--base64 Inline the Wasm module using base64 encoding
--fetch PATH Load module by passing the PATH argument to `fetch()`
Note that this is not intended to produce a production-ready output module

6
crates/cli/tests/reference.rs
View File

@ -1,8 +1,8 @@
//! A test suite to check the reference JS and wasm output of the `wasm-bindgen`
//! A test suite to check the reference JS and Wasm output of the `wasm-bindgen`
//! library.
//!
//! This is intended as an end-to-end integration test where we can track
//! changes to the JS and wasm output.
//! changes to the JS and Wasm output.
//!
//! Tests are located in `reference/*.rs` files and are accompanied with sibling
//! `*.js` files and `*.wat` files with the expected output of the `*.rs`
@ -127,7 +127,7 @@ fn assert_same(output: &str, expected: &Path) -> Result<()> {
}
fn sanitize_wasm(wasm: &Path) -> Result<String> {
// Clean up the wasm module by removing all function
// Clean up the Wasm module by removing all function
// implementations/instructions, data sections, etc. This'll help us largely
// only deal with exports/imports which is all we're really interested in.
let mut module = ModuleConfig::new()

12
crates/externref-xform/src/lib.rs
View File

@ -2,7 +2,7 @@
//! module.
//!
//! This crate is in charge of enabling code using `wasm-bindgen` to use the
//! `externref` type inside of the wasm module. This transformation pass primarily
//! `externref` type inside of the Wasm module. This transformation pass primarily
//! wraps exports and imports in shims which use `externref`, but quickly turn them
//! into `i32` value types. This is all largely a stopgap until Rust has
//! first-class support for the `externref` type, but that's thought to be in the
@ -11,9 +11,9 @@
//!
//! The pass here works by collecting information during binding generation
//! about imports and exports. Afterwards this pass runs in one go against a
//! wasm module, updating exports, imports, calls to these functions, etc. The
//! goal at least is to have valid wasm modules coming in that don't use
//! `externref` and valid wasm modules going out which use `externref` at the fringes.
//! Wasm module, updating exports, imports, calls to these functions, etc. The
//! goal at least is to have valid Wasm modules coming in that don't use
//! `externref` and valid Wasm modules going out which use `externref` at the fringes.
use anyhow::{anyhow, bail, Context as _, Error};
use std::cmp;
@ -97,7 +97,7 @@ enum Intrinsic {
}
impl Context {
/// Executed first very early over a wasm module, used to learn about how
/// Executed first very early over a Wasm module, used to learn about how
/// large the function table is so we know what indexes to hand out when
/// we're appending entries.
pub fn prepare(&mut self, module: &mut Module) -> Result<(), Error> {
@ -669,7 +669,7 @@ impl Transform<'_> {
//
// Note that we pave over all our stack slots with `ref.null` to ensure
// that the table doesn't accidentally hold a strong reference to items
// no longer in use by our wasm instance.
// no longer in use by our Wasm instance.
if externref_stack > 0 {
body.local_get(fp)
.ref_null(RefType::Externref)

6
crates/futures/src/lib.rs
View File

@ -204,13 +204,13 @@ impl Future for JsFuture {
///
/// # Panics
///
/// Note that in wasm panics are currently translated to aborts, but "abort" in
/// this case means that a JavaScript exception is thrown. The wasm module is
/// Note that in Wasm panics are currently translated to aborts, but "abort" in
/// this case means that a JavaScript exception is thrown. The Wasm module is
/// still usable (likely erroneously) after Rust panics.
///
/// If the `future` provided panics then the returned `Promise` **will not
/// resolve**. Instead it will be a leaked promise. This is an unfortunate
/// limitation of wasm currently that's hoped to be fixed one day!
/// limitation of Wasm currently that's hoped to be fixed one day!
pub fn future_to_promise<F>(future: F) -> Promise
where
F: Future<Output = Result<JsValue, JsValue>> + 'static,

10
crates/js-sys/src/lib.rs
View File

@ -4406,7 +4406,7 @@ pub mod WebAssembly {
/// The `WebAssembly.instantiateStreaming()` function compiles and
/// instantiates a WebAssembly module directly from a streamed
/// underlying source. This is the most efficient, optimized way to load
/// wasm code.
/// Wasm code.
///
/// [MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiateStreaming)
#[wasm_bindgen(js_namespace = WebAssembly, js_name = instantiateStreaming)]
@ -4414,7 +4414,7 @@ pub mod WebAssembly {
/// The `WebAssembly.validate()` function validates a given typed
/// array of WebAssembly binary code, returning whether the bytes
/// form a valid wasm module (`true`) or not (`false`).
/// form a valid Wasm module (`true`) or not (`false`).
///
/// [MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/validate)
#[wasm_bindgen(js_namespace = WebAssembly, catch)]
@ -6283,7 +6283,7 @@ macro_rules! arrays {
/// Rust pointer.
///
/// This function will efficiently copy the memory from a typed
/// array into this wasm module's own linear memory, initializing
/// array into this Wasm module's own linear memory, initializing
/// the memory destination provided.
///
/// # Unsafety
@ -6302,7 +6302,7 @@ macro_rules! arrays {
/// Rust slice.
///
/// This function will efficiently copy the memory from a typed
/// array into this wasm module's own linear memory, initializing
/// array into this Wasm module's own linear memory, initializing
/// the memory destination provided.
///
/// # Panics
@ -6318,7 +6318,7 @@ macro_rules! arrays {
/// JS typed array.
///
/// This function will efficiently copy the memory from within
/// the wasm module's own linear memory to this typed array.
/// the Wasm module's own linear memory to this typed array.
///
/// # Panics
///

2
crates/macro-support/src/parser.rs
View File

@ -1059,7 +1059,7 @@ impl<'a> MacroParse<(Option<BindgenAttrs>, &'a mut TokenStream)> for syn::Item {
}
let comments = extract_doc_comments(&f.attrs);
// If the function isn't used for anything other than being exported to JS,
// it'll be unused when not building for the wasm target and produce a
// it'll be unused when not building for the Wasm target and produce a
// `dead_code` warning. So, add `#[allow(dead_code)]` before it to avoid that.
tokens.extend(quote::quote! { #[allow(dead_code)] });
f.to_tokens(tokens);

2
crates/multi-value-xform/src/lib.rs
View File

@ -74,7 +74,7 @@
//! local.get 1
//! call $pair
//!
//! ;; Copy the return values from the stack to the wasm stack.
//! ;; Copy the return values from the stack to the Wasm stack.
//! local.get 2
//! i32.load
//! local.get 2 offset=4

10
crates/test/README.md
View File

@ -34,7 +34,7 @@ provides the support for:
* Catching JS exceptions so tests can continue to run after a test fails
* Driving execution of all tests
This is the crate which you actually link to in your wasm test and through which
This is the crate which you actually link to in your Wasm test and through which
you import the `#[wasm_bindgen_test]` macro. Otherwise this crate provides a
`console_log!` macro that's a utility like `println!` only using `console.log`.
@ -46,7 +46,7 @@ bare bones!
This is where the secret sauce comes into play. We configured Cargo to execute
this binary *instead* of directly executing the `*.wasm` file (which Cargo would
otherwise try to do). This means that whenever a test is executed it executes
this binary with the wasm file as an argument, allowing it to take full control
this binary with the Wasm file as an argument, allowing it to take full control
over the test process!
The test runner is currently pretty simple, executing a few steps:
@ -59,8 +59,8 @@ The test runner is currently pretty simple, executing a few steps:
tests.
In essence what happens is that this test runner automatically executes
`wasm-bindgen` and then uses Node to actually execute the wasm file, meaning
that your wasm code currently runs in a Node environment.
`wasm-bindgen` and then uses Node to actually execute the Wasm file, meaning
that your Wasm code currently runs in a Node environment.
## Future Work
@ -68,5 +68,5 @@ Things that'd be awesome to support in the future:
* Arguments to `wasm-bindgen-test-runner` which are the same as `wasm-bindgen`,
for example `--debug` to affect the generated output.
* Running each test in its own wasm instance to avoid poisoning the environment
* Running each test in its own Wasm instance to avoid poisoning the environment
on panic

16
crates/test/src/rt/mod.rs
View File

@ -6,8 +6,8 @@
// # Architecture of `wasm_bindgen_test`
//
// This module can seem a bit funky, but it's intended to be the runtime support
// of the `#[wasm_bindgen_test]` macro and be amenable to executing wasm test
// suites. The general idea is that for a wasm test binary there will be a set
// of the `#[wasm_bindgen_test]` macro and be amenable to executing Wasm test
// suites. The general idea is that for a Wasm test binary there will be a set
// of functions tagged `#[wasm_bindgen_test]`. It's the job of the runtime
// support to execute all of these functions, collecting and collating the
// results.
@ -22,11 +22,11 @@
//
// * First, the user runs `cargo test --target wasm32-unknown-unknown`
//
// * Cargo then compiles all the test suites (aka `tests/*.rs`) as wasm binaries
// * Cargo then compiles all the test suites (aka `tests/*.rs`) as Wasm binaries
// (the `bin` crate type). These binaries all have entry points that are
// `main` functions, but it's actually not used. The binaries are also
// compiled with `--test`, which means they're linked to the standard `test`
// crate, but this crate doesn't work on wasm and so we bypass it entirely.
// crate, but this crate doesn't work on Wasm and so we bypass it entirely.
//
// * Instead of using `#[test]`, which doesn't work, users wrote tests with
// `#[wasm_bindgen_test]`. This macro expands to a bunch of `#[no_mangle]`
@ -44,7 +44,7 @@
//
// * The `wasm-bindgen-test-runner` binary generates a JS entry point. This
// entry point creates a `Context` below. The runner binary also parses the
// wasm file and finds all functions that are named `__wbg_test_*`. The
// Wasm file and finds all functions that are named `__wbg_test_*`. The
// generate file gathers up all these functions into an array and then passes
// them to `Context` below. Note that these functions are passed as *JS
// values*.
@ -61,7 +61,7 @@
// This is used for test filters today.
//
// * The `Context::run` function is called. Again, the generated JS has gathered
// all wasm tests to be executed into a list, and it's passed in here.
// all Wasm tests to be executed into a list, and it's passed in here.
//
// * Next, `Context::run` returns a `Promise` representing the eventual
// execution of all the tests. The Rust `Future` that's returned will work
@ -351,7 +351,7 @@ impl Context {
.writeln(&format!("running {} {}", tests.len(), noun));
self.state.formatter.writeln("");
// Execute all our test functions through their wasm shims (unclear how
// Execute all our test functions through their Wasm shims (unclear how
// to pass native function pointers around here). Each test will
// execute one of the `execute_*` tests below which will push a
// future onto our `remaining` list, which we'll process later.
@ -726,7 +726,7 @@ impl State {
/// variable to capture output for the current test. That way at least when
/// we've got Rust code running we'll be able to capture output.
///
/// * Next, this "catches panics". Right now all wasm code is configured as
/// * Next, this "catches panics". Right now all Wasm code is configured as
/// panic=abort, but it's more like an exception in JS. It's pretty sketchy
/// to actually continue executing Rust code after an "abort", but we don't
/// have much of a choice for now.

6
crates/threads-xform/src/lib.rs
View File

@ -55,9 +55,9 @@ impl Config {
}
}
/// Specify the maximum amount of memory the wasm module can ever have.
/// Specify the maximum amount of memory the Wasm module can ever have.
///
/// We'll be specifying that the memory for this wasm module is shared, and
/// We'll be specifying that the memory for this Wasm module is shared, and
/// all shared memories must have their maximum limit specified (whereas
/// by default Rust/LLVM/LLD don't specify a maximum).
///
@ -87,7 +87,7 @@ impl Config {
self
}
/// Execute the transformation on the parsed wasm module specified.
/// Execute the transformation on the parsed Wasm module specified.
///
/// This function will prepare `Module` to be run on multiple threads,
/// performing steps such as:

16
crates/wasm-interpreter/src/lib.rs
View File

@ -1,8 +1,8 @@
//! A tiny and incomplete wasm interpreter
//! A tiny and incomplete Wasm interpreter
//!
//! This module contains a tiny and incomplete wasm interpreter built on top of
//! This module contains a tiny and incomplete Wasm interpreter built on top of
//! `walrus`'s module structure. Each `Interpreter` contains some state
//! about the execution of a wasm instance. The "incomplete" part here is
//! about the execution of a Wasm instance. The "incomplete" part here is
//! related to the fact that this is *only* used to execute the various
//! descriptor functions for wasm-bindgen.
//!
@ -23,11 +23,11 @@ use std::collections::{BTreeMap, BTreeSet, HashMap};
use walrus::ir::Instr;
use walrus::{ElementId, FunctionId, LocalId, Module, TableId};
/// A ready-to-go interpreter of a wasm module.
/// A ready-to-go interpreter of a Wasm module.
///
/// An interpreter currently represents effectively cached state. It is reused
/// between calls to `interpret` and is precomputed from a `Module`. It houses
/// state like the wasm stack, wasm memory, etc.
/// state like the Wasm stack, Wasm memory, etc.
#[derive(Default)]
pub struct Interpreter {
// Function index of the `__wbindgen_describe` and
@ -43,7 +43,7 @@ pub struct Interpreter {
// functions.
name_map: HashMap<String, FunctionId>,
// The current stack pointer (global 0) and wasm memory (the stack). Only
// The current stack pointer (global 0) and Wasm memory (the stack). Only
// used in a limited capacity.
sp: i32,
mem: Vec<i32>,
@ -70,7 +70,7 @@ impl Interpreter {
let mut ret = Interpreter::default();
// Give ourselves some memory and set the stack pointer
// (the LLVM call stack, now the wasm stack, global 0) to the top.
// (the LLVM call stack, now the Wasm stack, global 0) to the top.
ret.mem = vec![0; 0x8000];
ret.sp = ret.mem.len() as i32;
@ -130,7 +130,7 @@ impl Interpreter {
pub fn interpret_descriptor(&mut self, id: FunctionId, module: &Module) -> Option<&[u32]> {
self.descriptor.truncate(0);
// We should have a blank wasm and LLVM stack at both the start and end
// We should have a blank Wasm and LLVM stack at both the start and end
// of the call.
assert_eq!(self.sp, self.mem.len() as i32);
self.call(id, module, &[]);

2
examples/add/README.md
View File

@ -1,4 +1,4 @@
# Adding numbers (small wasm files)
# Adding numbers (small Wasm files)
[View documentation for this example online][dox] or [View compiled example
online][compiled]

2
examples/console_log/src/lib.rs
View File

@ -37,7 +37,7 @@ fn bare_bones() {
}
// Next let's define a macro that's like `println!`, only it works for
// `console.log`. Note that `println!` doesn't actually work on the wasm target
// `console.log`. Note that `println!` doesn't actually work on the Wasm target
// because the standard library currently just eats all output. To get
// `println!`-like behavior in your app you'll likely want a macro like this.

2
examples/deno/README.md
View File

@ -12,5 +12,5 @@ and test it with
$ deno run --allow-read test.ts
```
The `--allow-read` flag is needed because the wasm file is read during runtime.
The `--allow-read` flag is needed because the Wasm file is read during runtime.
This will be fixed when https://github.com/denoland/deno/issues/2552 is resolved.

2
examples/raytrace-parallel/build.py
View File

@ -31,7 +31,7 @@ subprocess.run(
).check_returncode()
# Note the usage of `--target no-modules` here which is required for passing
# the memory import to each wasm module.
# the memory import to each Wasm module.
subprocess.run(
[
"cargo",

2
examples/raytrace-parallel/index.js
View File

@ -22,7 +22,7 @@ function loadWasm() {
const buf = new Uint8Array([0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00,
0x05, 0x03, 0x01, 0x00, 0x01, 0x0b, 0x03, 0x01, 0x01, 0x00]);
if (!WebAssembly.validate(buf)) {
alert('this browser does not support passive wasm memory, demo does not work' + '\n\n' + msg);
alert('this browser does not support passive Wasm memory, demo does not work' + '\n\n' + msg);
return
}

2
examples/raytrace-parallel/src/lib.rs
View File

@ -149,7 +149,7 @@ fn image_data(base: usize, len: usize, width: u32, height: u32) -> ImageData {
//
// FIXME: that this may or may not be UB based on Rust's rules. For example
// threads may be doing unsynchronized writes to pixel data as we read it
// off here. In the context of wasm this may or may not be UB, we're
// off here. In the context of Wasm this may or may not be UB, we're
// unclear! In any case for now it seems to work and produces a nifty
// progressive rendering. A more production-ready application may prefer to
// instead use some form of signaling here to request an update from the

6
examples/raytrace-parallel/src/pool.rs
View File

@ -59,7 +59,7 @@ impl WorkerPool {
/// Unconditionally spawns a new worker
///
/// The worker isn't registered with this `WorkerPool` but is capable of
/// executing work for this wasm module.
/// executing work for this Wasm module.
///
/// # Errors
///
@ -76,8 +76,8 @@ impl WorkerPool {
let worker = Worker::new("./worker.js")?;
// With a worker spun up send it the module/memory so it can start
// instantiating the wasm module. Later it might receive further
// messages about code to run on the wasm module.
// instantiating the Wasm module. Later it might receive further
// messages about code to run on the Wasm module.
let array = js_sys::Array::new();
array.push(&wasm_bindgen::module());
array.push(&wasm_bindgen::memory());

2
examples/request-animation-frame/src/lib.rs
View File

@ -22,7 +22,7 @@ fn body() -> web_sys::HtmlElement {
document().body().expect("document should have a body")
}
// This function is automatically invoked after the wasm module is instantiated.
// This function is automatically invoked after the Wasm module is instantiated.
#[wasm_bindgen(start)]
fn run() -> Result<(), JsValue> {
// Here we want to call `requestAnimationFrame` in a loop, but only a fixed

2
examples/wasm-audio-worklet/build.py
View File

@ -31,7 +31,7 @@ subprocess.run(
).check_returncode()
# Note the usage of `--target no-modules` here which is required for passing
# the memory import to each wasm module.
# the memory import to each Wasm module.
subprocess.run(
[
"cargo",

4
examples/wasm-audio-worklet/src/wasm_audio.rs
View File

@ -20,7 +20,7 @@ impl WasmAudioProcessor {
}
}
// Use wasm_audio if you have a single wasm audio processor in your application
// Use wasm_audio if you have a single Wasm audio processor in your application
// whose samples should be played directly. Ideally, call wasm_audio based on
// user interaction. Otherwise, resume the context on user interaction, so
// playback starts reliably on all browsers.
@ -34,7 +34,7 @@ pub async fn wasm_audio(
Ok(ctx)
}
// wasm_audio_node creates an AudioWorkletNode running a wasm audio processor.
// wasm_audio_node creates an AudioWorkletNode running a Wasm audio processor.
// Remember to call prepare_wasm_audio once on your context before calling
// this function.
pub fn wasm_audio_node(

2
examples/wasm-in-wasm-imports/src/lib.rs
View File

@ -23,7 +23,7 @@ macro_rules! console_error {
const WASM: &[u8] = include_bytes!("native_add.wasm");
async fn run_async() -> Result<(), JsValue> {
console_log!("instantiating a new wasm module directly");
console_log!("instantiating a new Wasm module directly");
let imports = make_imports()?;
let a = JsFuture::from(WebAssembly::instantiate_buffer(WASM, &imports)).await?;

2
examples/wasm-in-wasm/src/lib.rs
View File

@ -16,7 +16,7 @@ macro_rules! console_log {
const WASM: &[u8] = include_bytes!("add.wasm");
async fn run_async() -> Result<(), JsValue> {
console_log!("instantiating a new wasm module directly");
console_log!("instantiating a new Wasm module directly");
let a = JsFuture::from(WebAssembly::instantiate_buffer(WASM, &Object::new())).await?;
let b: WebAssembly::Instance = Reflect::get(&a, &"instance".into())?.dyn_into()?;

2
examples/wasm-in-web-worker/index.js
View File

@ -4,7 +4,7 @@
const {startup} = wasm_bindgen;
async function run_wasm() {
// Load the wasm file by awaiting the Promise returned by `wasm_bindgen`
// Load the Wasm file by awaiting the Promise returned by `wasm_bindgen`
// `wasm_bindgen` was imported in `index.html`
await wasm_bindgen();

2
examples/wasm-in-web-worker/worker.js
View File

@ -10,7 +10,7 @@ console.log('Initializing worker')
const {NumberEval} = wasm_bindgen;
async function init_wasm_in_worker() {
// Load the wasm file by awaiting the Promise returned by `wasm_bindgen`.
// Load the Wasm file by awaiting the Promise returned by `wasm_bindgen`.
await wasm_bindgen('./pkg/wasm_in_web_worker_bg.wasm');
// Create a new object of the `NumberEval` struct.

2
examples/wasm2js/build.sh
View File

@ -2,7 +2,7 @@
set -ex
# Compile our wasm module and run `wasm-bindgen`
# Compile our Wasm module and run `wasm-bindgen`
wasm-pack build
# Run the `wasm2js` tool from `binaryen`

2
examples/without-a-bundler-no-modules/src/lib.rs
View File

@ -1,6 +1,6 @@
use wasm_bindgen::prelude::*;
// Called when the wasm module is instantiated
// Called when the Wasm module is instantiated
#[wasm_bindgen(start)]
fn main() -> Result<(), JsValue> {
// Use `web_sys`'s global `window` function to get a handle on the global

10
examples/without-a-bundler/index.html
View File

@ -15,14 +15,14 @@
import init, { add } from './pkg/without_a_bundler.js';
async function run() {
// First up we need to actually load the wasm file, so we use the
// default export to inform it where the wasm file is located on the
// First up we need to actually load the Wasm file, so we use the
// default export to inform it where the Wasm file is located on the
// server, and then we wait on the returned promise to wait for the
// wasm to be loaded.
// Wasm to be loaded.
//
// It may look like this: `await init('./pkg/without_a_bundler_bg.wasm');`,
// but there is also a handy default inside `init` function, which uses
// `import.meta` to locate the wasm file relatively to js file.
// `import.meta` to locate the Wasm file relatively to js file.
//
// Note that instead of a string you can also pass in any of the
// following things:
@ -38,7 +38,7 @@
// This gives you complete control over how the module is loaded
// and compiled.
//
// Also note that the promise, when resolved, yields the wasm module's
// Also note that the promise, when resolved, yields the Wasm module's
// exports which is the same as importing the `*_bg` module in other
// modes
await init();

2
examples/without-a-bundler/src/lib.rs
View File

@ -1,6 +1,6 @@
use wasm_bindgen::prelude::*;
// Called when the wasm module is instantiated
// Called when the Wasm module is instantiated
#[wasm_bindgen(start)]
fn main() -> Result<(), JsValue> {
// Use `web_sys`'s global `window` function to get a handle on the global

2
guide/src/SUMMARY.md
View File

@ -7,7 +7,7 @@
- [Examples](./examples/index.md)
- [Hello, World!](./examples/hello-world.md)
- [Using `console.log`](./examples/console-log.md)
- [Small wasm files](./examples/add.md)
- [Small Wasm files](./examples/add.md)
- [Without a Bundler](./examples/without-a-bundler.md)
- [Synchronous Instantiation](./examples/synchronous-instantiation.md)
- [Converting WebAssembly to JS](./examples/wasm2js.md)

4
guide/src/contributing/design/describe.md
View File

@ -8,7 +8,7 @@ reads.
To accomplish this a slightly unconventional approach is taken. Static
information about the structure of the Rust code is serialized via JSON
(currently) to a custom section of the wasm executable. Other information, like
(currently) to a custom section of the Wasm executable. Other information, like
what the types actually are, unfortunately isn't known until later in the
compiler due to things like associated type projections and typedefs. It also
turns out that we want to convey "rich" types like `FnMut(String, Foo,
@ -54,4 +54,4 @@ which fully describes a type.
All in all this is a bit roundabout but shouldn't have any impact on the
generated code or runtime at all. All these descriptor functions are pruned from
the emitted wasm file.
the emitted Wasm file.

16
guide/src/contributing/design/exporting-rust.md
View File

@ -5,8 +5,8 @@ let's take a look at another feature of `wasm-bindgen`: exporting functionality
with types that are richer than just numbers.
The basic idea around exporting functionality with more flavorful types is that
the wasm exports won't actually be called directly. Instead the generated
`foo.js` module will have shims for all exported functions in the wasm module.
the Wasm exports won't actually be called directly. Instead the generated
`foo.js` module will have shims for all exported functions in the Wasm module.
The most interesting conversion here happens with strings so let's take a look
at that.
@ -64,14 +64,14 @@ export function greet(arg0) {
Phew, that's quite a lot! We can sort of see though if we look closely what's
happening:
* Strings are passed to wasm via two arguments, a pointer and a length. Right
now we have to copy the string onto the wasm heap which means we'll be using
* Strings are passed to Wasm via two arguments, a pointer and a length. Right
now we have to copy the string onto the Wasm heap which means we'll be using
`TextEncoder` to actually do the encoding. Once this is done we use an
internal function in `wasm-bindgen` to allocate space for the string to go,
and then we'll pass that ptr/length to wasm later on.
and then we'll pass that ptr/length to Wasm later on.
* Returning strings from wasm is a little tricky as we need to return a ptr/len
pair, but wasm currently only supports one return value (multiple return values
* Returning strings from Wasm is a little tricky as we need to return a ptr/len
pair, but Wasm currently only supports one return value (multiple return values
[is being standardized](https://github.com/WebAssembly/design/issues/1146)).
To work around this in the meantime, we're actually returning a pointer to a
ptr/len pair, and then using functions to access the various fields.
@ -111,7 +111,7 @@ string slice, while the return value is boxed up into just a pointer and is
then returned up to was for reading via the `__wbindgen_boxed_str_*` functions.
So in general exporting a function involves a shim both in JS and in Rust with
each side translating to or from wasm arguments to the native types of each
each side translating to or from Wasm arguments to the native types of each
language. The `wasm-bindgen` tool manages hooking up all these shims while the
`#[wasm_bindgen]` macro takes care of the Rust shim as well.

10
guide/src/contributing/design/index.md
View File

@ -9,18 +9,18 @@ answer questions and/or update this!
The first thing to know about `wasm-bindgen` is that it's fundamentally built on
the idea of ES Modules. In other words this tool takes an opinionated stance
that wasm files *should be viewed as ES modules*. This means that you can
`import` from a wasm file, use its `export`-ed functionality, etc, from normal
that Wasm files *should be viewed as ES modules*. This means that you can
`import` from a Wasm file, use its `export`-ed functionality, etc, from normal
JS files.
Now unfortunately at the time of this writing the interface of wasm interop
Now unfortunately at the time of this writing the interface of Wasm interop
isn't very rich. Wasm modules can only call functions or export functions that
deal exclusively with `i32`, `i64`, `f32`, and `f64`. Bummer!
That's where this project comes in. The goal of `wasm-bindgen` is to enhance the
"ABI" of wasm modules with richer types like classes, JS objects, Rust structs,
"ABI" of Wasm modules with richer types like classes, JS objects, Rust structs,
strings, etc. Keep in mind, though, that everything is based on ES Modules! This
means that the compiler is actually producing a "broken" wasm file of sorts. The
means that the compiler is actually producing a "broken" Wasm file of sorts. The
wasm file emitted by rustc, for example, does not have the interface we would
like to have. Instead it requires the `wasm-bindgen` tool to postprocess the
file, generating a `foo.js` and `foo_bg.wasm` file. The `foo.js` file is the

18
guide/src/contributing/design/js-objects-in-rust.md
View File

@ -4,7 +4,7 @@ One of the main goals of `wasm-bindgen` is to allow working with and passing
around JS objects in wasm, but that's not allowed today! While indeed true,
that's where the polyfill comes in.
The question here is how we shoehorn JS objects into a `u32` for wasm to use.
The question here is how we shoehorn JS objects into a `u32` for Wasm to use.
The current strategy for this approach is to maintain a module-local variable
in the generated `foo.js` file: a `heap`.
@ -18,7 +18,7 @@ pushed.
JS objects are then only removed from the bottom of the stack as well. Removal
is simply storing null then incrementing a counter. Because of the "stack-y"
nature of this scheme it only works for when wasm doesn't hold onto a JS object
nature of this scheme it only works for when Wasm doesn't hold onto a JS object
(aka it only gets a "reference" in Rust parlance).
Let's take a look at an example.
@ -72,13 +72,13 @@ export function foo(arg0) {
Here we can see a few notable points of action:
* The wasm file was renamed to `foo_bg.wasm`, and we can see how the JS module
generated here is importing from the wasm file.
* The Wasm file was renamed to `foo_bg.wasm`, and we can see how the JS module
generated here is importing from the Wasm file.
* Next we can see our `heap` module variable which is to store all JS values
reference-able from wasm.
* Our exported function `foo`, takes an arbitrary argument, `arg0`, which is
converted to an index with the `addBorrowedObject` object function. The index
is then passed to wasm so wasm can operate with it.
is then passed to Wasm so Wasm can operate with it.
* Finally, we have a `finally` which frees the stack slot as it's no longer
used, popping the value that was pushed at the start of the function.
@ -105,7 +105,7 @@ And as with the JS, the notable points here are:
* The original function, `foo`, is unmodified in the output
* A generated function here (with a unique name) is the one that's actually
exported from the wasm module
exported from the Wasm module
* Our generated function takes an integer argument (our index) and then wraps it
in a `JsValue`. There's some trickery here that's not worth going into just
yet, but we'll see in a bit what's happening under the hood.
@ -118,8 +118,8 @@ dynamic lifetime or otherwise need to be stored on Rust's heap. To cope with
this there's a second half of management of JS objects, naturally corresponding
to the other side of the JS `heap` array.
JS Objects passed to wasm that are not references are assumed to have a dynamic
lifetime inside of the wasm module. As a result the strict push/pop of the stack
JS Objects passed to Wasm that are not references are assumed to have a dynamic
lifetime inside of the Wasm module. As a result the strict push/pop of the stack
won't work and we need more permanent storage for the JS objects. To cope with
this we build our own "slab allocator" of sorts.
@ -140,7 +140,7 @@ module interface is the same as before, but the ownership mechanics are slightly
different. Let's see the generated JS's slab in action:
```js
import * as wasm from './foo_bg'; // imports from wasm file
import * as wasm from './foo_bg'; // imports from Wasm file
const heap = new Array(32);
heap.push(undefined, null, true, false);

4
guide/src/examples/add.md
View File

@ -1,4 +1,4 @@
# Small wasm files
# Small Wasm files
[View full source code][code] or [view the compiled example online][online]
@ -15,7 +15,7 @@ Currently this code...
{{#include ../../../examples/add/src/lib.rs}}
```
generates a 710 byte wasm binary:
generates a 710 byte Wasm binary:
```
$ ls -l add_bg.wasm

12
guide/src/examples/raytrace.md
View File

@ -9,7 +9,7 @@ This is an example of using threads with WebAssembly, Rust, and `wasm-bindgen`,
culminating in a parallel raytracer demo. There's a number of moving pieces to
this demo and it's unfortunately not the easiest thing to wrangle, but it's
hoped that this'll give you a bit of a taste of what it's like to use threads
and wasm with Rust on the web.
and Wasm with Rust on the web.
### Building the demo
@ -68,7 +68,7 @@ post its memory object to all other threads to get instantiated with.
### Caveats
Unfortunately at this time running wasm on the web with threads has a number of
Unfortunately at this time running Wasm on the web with threads has a number of
caveats, although some are specific to just `wasm-bindgen`. These are some
pieces to consider and watch out for, although we're always looking for
improvements to be made so if you have an idea please file an issue!
@ -76,7 +76,7 @@ improvements to be made so if you have an idea please file an issue!
* The main thread in a browser cannot block. This means that if you run
WebAssembly code on the main thread you can *never* block, meaning you can't
do so much as acquire a mutex. This is an extremely difficult limitation to
work with on the web, although one workaround is to run wasm exclusively in
work with on the web, although one workaround is to run Wasm exclusively in
web workers and run JS on the main thread. It is possible to run the same wasm
across all threads, but you need to be extremely vigilant about
synchronization with the main thread.
@ -85,19 +85,19 @@ improvements to be made so if you have an idea please file an issue!
today. For example `--target bundler` is unsupported and very specific shims
are required on both the main thread and worker threads. These are possible to
work with but are somewhat brittle since there's no standard way to spin up
web workers as wasm threads.
web workers as Wasm threads.
* There is no standard notion of a "thread". For example the standard library
has no viable route to implement the `std::thread` module. As a consequence
there is no concept of thread exit and TLS destructors will never run.
We do expose a helper, `__wbindgen_thread_destroy`, that deallocates
the thread stack and TLS. If you invoke it, it *must* be the last function
you invoke from the wasm module for a given thread.
you invoke from the Wasm module for a given thread.
* Any thread launched after the first one _might attempt to block_ implicitly
in its initialization routine. This is a constraint introduced by the way
we set up the space for thread stacks and TLS. This means that if you attempt
to run a wasm module in the main thread _after_ you are already running it
to run a Wasm module in the main thread _after_ you are already running it
in a worker, it might fail.
* Web Workers executing WebAssembly code cannot receive events from JS. A Web

2
guide/src/examples/web-audio.md
View File

@ -31,7 +31,7 @@ The Rust code implements the FM oscillator.
## `index.js`
A small bit of JavaScript glues the rust module to input widgets and translates
events into calls into wasm code.
events into calls into Wasm code.
```js
{{#include ../../../examples/webaudio/index.js}}

2
guide/src/introduction.md
View File

@ -1,7 +1,7 @@
# Introduction
This book is about `wasm-bindgen`, a Rust library and CLI tool that facilitate
high-level interactions between wasm modules and JavaScript. The `wasm-bindgen`
high-level interactions between Wasm modules and JavaScript. The `wasm-bindgen`
tool and crate are only one part of the [Rust and WebAssembly
ecosystem][rustwasm]. If you're not familiar already with `wasm-bindgen` it's
recommended to start by reading the [Game of Life tutorial][gol]. If you're

6
guide/src/reference/attributes/on-js-imports/catch.md
View File

@ -22,8 +22,8 @@ If calling the imported function throws an exception, then `Err` will be
returned with the exception that was raised. Otherwise, `Ok` is returned with
the result of the function.
> By default `wasm-bindgen` will take no action when wasm calls a JS function
> which ends up throwing an exception. The wasm spec right now doesn't support
> By default `wasm-bindgen` will take no action when Wasm calls a JS function
> which ends up throwing an exception. The Wasm spec right now doesn't support
> stack unwinding and as a result Rust code **will not execute destructors**.
> This can unfortunately cause memory leaks in Rust right now, but as soon as
> wasm implements catching exceptions we'll be sure to add support as well!
> Wasm implements catching exceptions we'll be sure to add support as well!

4
guide/src/reference/attributes/on-js-imports/final.md
View File

@ -140,10 +140,10 @@ export const __wbg_bar_a81456386e6b526f = Foo.prototype.bar;
and voila! We, with [reference types][reference-types] and [component
model][component-model], now have no JS function shim at all necessary to call
the imported function. Additionally future wasm proposals to the ES module
the imported function. Additionally future Wasm proposals to the ES module
system may also mean that don't even need the `export const ...` here too.
It's also worth pointing out that with all these wasm proposals implemented the
It's also worth pointing out that with all these Wasm proposals implemented the
default way to import the `bar` function (aka `structural`) would generate a JS
function shim that looks like:

2
guide/src/reference/attributes/on-js-imports/raw_module.md
View File

@ -14,6 +14,6 @@ extern "C" {
Note that if you use this attribute with a relative or absolute path, it's
likely up to the final bundler or project to assign meaning to that path. This
typically means that the JS file or module will be resolved relative to the
final location of the wasm file itself. That means that `raw_module` is likely
final location of the Wasm file itself. That means that `raw_module` is likely
unsuitable for libraries on crates.io, but may be usable within end-user
applications.

2
guide/src/reference/attributes/on-js-imports/variadic.md
View File

@ -23,7 +23,7 @@ function sum(...rest) {
```
This function doesn't translate directly into rust, since we don't currently support variadic
arguments on the wasm target. To bind to it, we use a slice as the last argument, and annotate the
arguments on the Wasm target. To bind to it, we use a slice as the last argument, and annotate the
function as variadic:
```rust

6
guide/src/reference/attributes/on-rust-exports/start.md
View File

@ -1,8 +1,8 @@
# `start`
When attached to a function this attribute will configure the `start`
section of the wasm executable to be emitted, executing the tagged function as
soon as the wasm module is instantiated.
section of the Wasm executable to be emitted, executing the tagged function as
soon as the Wasm module is instantiated.
```rust
#[wasm_bindgen(start)]
@ -11,7 +11,7 @@ fn start() {
}
```
The `start` section of the wasm executable will be configured to execute the
The `start` section of the Wasm executable will be configured to execute the
`start` function here as soon as it can. Note that due to various practical
limitations today the start section of the executable may not literally point to
`start`, but the `start` function here should be started up automatically when the

2
guide/src/reference/browser-support.md
View File

@ -15,7 +15,7 @@ also like to be aware of it!
* **IE 11** - `wasm-bindgen` by default requires support for
`WebAssembly`, but no version of IE currently supports `WebAssembly`. You can
support IE by [compiling wasm files to JS using `wasm2js`][w2js] (you can [see
support IE by [compiling Wasm files to JS using `wasm2js`][w2js] (you can [see
an example of doing this too](../examples/wasm2js.html)). Note
that at this time no bundler will do this by default, but we'd love to
document plugins which do this if you are aware of one!

2
guide/src/reference/cli.md
View File

@ -60,7 +60,7 @@ where the imports are instead handled through a separate preload script.
### `--debug`
Generates a bit more JS and wasm in "debug mode" to help catch programmer
Generates a bit more JS and Wasm in "debug mode" to help catch programmer
errors, but this output isn't intended to be shipped to production.
### `--no-demangle`

6
guide/src/reference/deployment.md
View File

@ -28,13 +28,13 @@ The methods of deployment and integration here are primarily tied to the
**`--target bundler`**
The default output of `wasm-bindgen`, or the `bundler` target, assumes a model
where the wasm module itself is natively an ES module. This model, however, is not
where the Wasm module itself is natively an ES module. This model, however, is not
natively implemented in any JS implementation at this time. As a result, to
consume the default output of `wasm-bindgen` you will need a bundler of some
form.
> **Note**: the choice of this default output was done to reflect the trends of
> the JS ecosystem. While tools other than bundlers don't support wasm files as
> the JS ecosystem. While tools other than bundlers don't support Wasm files as
> native ES modules today they're all very much likely to in the future!
Currently the only known bundler known to be fully compatible with
@ -82,7 +82,7 @@ native module), then you'll want to pass the `--target nodejs` flag to `wasm-bin
Like the "without a bundler" strategy, this method of deployment does not
require any further postprocessing. The generated JS shims can be `require`'d
just like any other Node module (even the `*_bg` wasm file can be `require`'d
just like any other Node module (even the `*_bg` Wasm file can be `require`'d
as it has a JS shim generated as well).
Note that this method requires a version of Node.js with WebAssembly support,

4
guide/src/reference/optimize-size.md
View File

@ -1,7 +1,7 @@
# Optimizing for Size with `wasm-bindgen`
The Rust and WebAssembly Working Group's [Game of Life tutorial][gol] has an
excellent section on [shrinking wasm code size][size], but there's a few
excellent section on [shrinking Wasm code size][size], but there's a few
`wasm-bindgen`-specific items to mention as well!
First and foremost, `wasm-bindgen` is designed to be lightweight and a "pay only
@ -40,7 +40,7 @@ This leaves us with two primary generated files to measure the size of:
### Example
As an example, the `wasm-bindgen` repository [contains an example][example]
about generating small wasm binaries and shows off how to generate a small wasm
about generating small Wasm binaries and shows off how to generate a small wasm
file for adding two numbers.
[gol]: https://rustwasm.github.io/book/game-of-life/introduction.html

4
guide/src/reference/reference-types.md
View File

@ -4,7 +4,7 @@ WebAssembly recently has gained support for a new value type called `externref`.
Proposed in the [WebAssembly reference types
repo](https://github.com/webassembly/reference-types) this feature of
WebAssembly is hoped to enable more efficient communication between the host
(JS) and the wasm module. This feature removes the need for much of the JS glue
(JS) and the Wasm module. This feature removes the need for much of the JS glue
generated by `wasm-bindgen` because it can natively call APIs with JS values.
For example, this Rust function:
@ -41,7 +41,7 @@ export function takes_js_value(a) {
```
We can see here how under the hood the JS is managing a table of JS values which
are passed to the wasm binary, so wasm actually only works in indices. If we
are passed to the Wasm binary, so Wasm actually only works in indices. If we
pass the `--reference-types` flag to the CLI, however, the generated JS looks like:
```js

2
guide/src/reference/types/result.md
View File

@ -11,7 +11,7 @@ it's converted to JS and handed off, and whenever `Err(error)` is encountered
an exception is thrown in JS with `error`.
You can use `Result` to enable handling of JS exceptions with `?` in Rust,
naturally propagating it upwards to the wasm boundary. Furthermore you can also
naturally propagating it upwards to the Wasm boundary. Furthermore you can also
return custom types in Rust so long as they're all convertible to `JsValue`.
Note that if you import a JS function with `Result` you need

2
guide/src/wasm-bindgen-test/continuous-integration.md
View File

@ -21,7 +21,7 @@ install:
script:
# this will test the non wasm targets if your crate has those, otherwise remove this line.
# this will test the non Wasm targets if your crate has those, otherwise remove this line.
#
- cargo test

4
guide/src/wasm-bindgen-test/index.md
View File

@ -1,12 +1,12 @@
# Testing on `wasm32-unknown-unknown` with `wasm-bindgen-test`
The `wasm-bindgen-test` crate is an experimental test harness for Rust programs
compiled to wasm using `wasm-bindgen` and the `wasm32-unknown-unknown`
compiled to Wasm using `wasm-bindgen` and the `wasm32-unknown-unknown`
target.
## Goals
* Write tests for wasm as similar as possible to how you normally would write
* Write tests for Wasm as similar as possible to how you normally would write
`#[test]`-style unit tests for native targets.
* Run the tests with the usual `cargo test` command but with an explicit wasm

2
releases/release-announcement-template.md
View File

@ -1,6 +1,6 @@
# Announcing `wasm-bindgen` $TODO_VERSION
`wasm-bindgen` facilitates high-level interactions between wasm modules and
`wasm-bindgen` facilitates high-level interactions between Wasm modules and
JavaScript.
* [GitHub][]

2
src/convert/impls.rs
View File

@ -508,7 +508,7 @@ where
//
// This is only a problem in debug mode. Since this is the browser's error stack
// we're talking about, it can only see functions that actually make it to the
// final wasm binary (i.e., not inlined functions). All of those internal
// final Wasm binary (i.e., not inlined functions). All of those internal
// iterator functions get inlined in release mode, and so they don't show up.
result.push(
T::try_from_js_value(value).expect_throw("array contains a value of the wrong type"),

2
src/convert/slices.rs
View File

@ -230,7 +230,7 @@ impl WasmDescribeVector for String {
fn describe_vector() {
inform(VECTOR);
inform(NAMED_EXTERNREF);
// Trying to use an actual loop for this breaks the wasm interpreter.
// Trying to use an actual loop for this breaks the Wasm interpreter.
inform(6);
inform('s' as u32);
inform('t' as u32);

16
src/convert/traits.rs
View File

@ -5,7 +5,7 @@ use crate::describe::*;
use crate::JsValue;
/// A trait for anything that can be converted into a type that can cross the
/// wasm ABI directly, eg `u32` or `f64`.
/// Wasm ABI directly, eg `u32` or `f64`.
///
/// This is the opposite operation as `FromWasmAbi` and `Ref[Mut]FromWasmAbi`.
///
@ -15,7 +15,7 @@ use crate::JsValue;
/// stability guarantees** are provided. Use at your own risk. See its
/// documentation for more details.
pub trait IntoWasmAbi: WasmDescribe {
/// The wasm ABI type that this converts into when crossing the ABI
/// The Wasm ABI type that this converts into when crossing the ABI
/// boundary.
type Abi: WasmAbi;
@ -24,8 +24,8 @@ pub trait IntoWasmAbi: WasmDescribe {
fn into_abi(self) -> Self::Abi;
}
/// A trait for anything that can be recovered by-value from the wasm ABI
/// boundary, eg a Rust `u8` can be recovered from the wasm ABI `u32` type.
/// A trait for anything that can be recovered by-value from the Wasm ABI
/// boundary, eg a Rust `u8` can be recovered from the Wasm ABI `u32` type.
///
/// This is the by-value variant of the opposite operation as `IntoWasmAbi`.
///
@ -35,7 +35,7 @@ pub trait IntoWasmAbi: WasmDescribe {
/// stability guarantees** are provided. Use at your own risk. See its
/// documentation for more details.
pub trait FromWasmAbi: WasmDescribe {
/// The wasm ABI type that this converts from when coming back out from the
/// The Wasm ABI type that this converts from when coming back out from the
/// ABI boundary.
type Abi: WasmAbi;
@ -50,7 +50,7 @@ pub trait FromWasmAbi: WasmDescribe {
}
/// A trait for anything that can be recovered as some sort of shared reference
/// from the wasm ABI boundary.
/// from the Wasm ABI boundary.
///
/// This is the shared reference variant of the opposite operation as
/// `IntoWasmAbi`.
@ -61,7 +61,7 @@ pub trait FromWasmAbi: WasmDescribe {
/// stability guarantees** are provided. Use at your own risk. See its
/// documentation for more details.
pub trait RefFromWasmAbi: WasmDescribe {
/// The wasm ABI type references to `Self` are recovered from.
/// The Wasm ABI type references to `Self` are recovered from.
type Abi: WasmAbi;
/// The type that holds the reference to `Self` for the duration of the
@ -222,7 +222,7 @@ pub trait WasmAbi {
}
/// A trait representing how to interpret the return value of a function for
/// the wasm ABI.
/// the Wasm ABI.
///
/// This is very similar to the `IntoWasmAbi` trait and in fact has a blanket
/// implementation for all implementors of the `IntoWasmAbi`. The primary use

18
src/lib.rs
View File

@ -88,7 +88,7 @@ if_std! {
///
/// A `JsValue` doesn't actually live in Rust right now but actually in a table
/// owned by the `wasm-bindgen` generated JS glue code. Eventually the ownership
/// will transfer into wasm directly and this will likely become more efficient,
/// will transfer into Wasm directly and this will likely become more efficient,
/// but for now it may be slightly slow.
pub struct JsValue {
idx: u32,
@ -276,7 +276,7 @@ impl JsValue {
}
/// If this JS value is a string value, this function copies the JS string
/// value into wasm linear memory, encoded as UTF-8, and returns it as a
/// value into Wasm linear memory, encoded as UTF-8, and returns it as a
/// Rust `String`.
///
/// To avoid the copying and re-encoding, consider the
@ -1213,7 +1213,7 @@ pub fn throw(s: &str) -> ! {
/// Throws a JS exception.
///
/// This function will throw a JS exception with the message provided. The
/// function will not return as the wasm stack will be popped when the exception
/// function will not return as the Wasm stack will be popped when the exception
/// is thrown.
///
/// Note that it is very easy to leak memory with this function because this
@ -1231,8 +1231,8 @@ pub fn throw_str(s: &str) -> ! {
/// Rethrow a JS exception
///
/// This function will throw a JS exception with the JS value provided. This
/// function will not return and the wasm stack will be popped until the point
/// of entry of wasm itself.
/// function will not return and the Wasm stack will be popped until the point
/// of entry of Wasm itself.
///
/// Note that it is very easy to leak memory with this function because this
/// function, unlike `panic!` on other platforms, **will not run destructors**.
@ -1306,7 +1306,7 @@ pub fn anyref_heap_live_count() -> u32 {
///
/// These methods should have a smaller code size footprint than the normal
/// `Option::unwrap` and `Option::expect` methods, but they are specific to
/// working with wasm and JS.
/// working with Wasm and JS.
///
/// On non-wasm32 targets, defaults to the normal unwrap/expect calls.
///
@ -1485,17 +1485,17 @@ pub fn module() -> JsValue {
unsafe { JsValue::_new(__wbindgen_module()) }
}
/// Returns a handle to this wasm instance's `WebAssembly.Instance.prototype.exports`
/// Returns a handle to this Wasm instance's `WebAssembly.Instance.prototype.exports`
pub fn exports() -> JsValue {
unsafe { JsValue::_new(__wbindgen_exports()) }
}
/// Returns a handle to this wasm instance's `WebAssembly.Memory`
/// Returns a handle to this Wasm instance's `WebAssembly.Memory`
pub fn memory() -> JsValue {
unsafe { JsValue::_new(__wbindgen_memory()) }
}
/// Returns a handle to this wasm instance's `WebAssembly.Table` which is the
/// Returns a handle to this Wasm instance's `WebAssembly.Table` which is the
/// indirect function table used by Rust
pub fn function_table() -> JsValue {
unsafe { JsValue::_new(__wbindgen_function_table()) }