diff --git a/CHANGELOG.md b/CHANGELOG.md index b5ef4213c6d..ee519b69adc 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -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. -------------------------------------------------------------------------------- diff --git a/README.md b/README.md index a9d57ee0a4e..d8e07bc0952 100644 --- a/README.md +++ b/README.md @@ -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. diff --git a/benchmarks/index.html b/benchmarks/index.html index 49cf021333a..b20d27e5d45 100644 --- a/benchmarks/index.html +++ b/benchmarks/index.html @@ -56,7 +56,7 @@

JS / wasm-bindgen comparison

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.

@@ -131,7 +131,7 @@

JS / wasm-bindgen comparison

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.

@@ -296,7 +296,7 @@

wasm-bindgen benchmarks

(?)

- 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.

diff --git a/benchmarks/index.js b/benchmarks/index.js index e74d8781da5..a8cbae01e77 100644 --- a/benchmarks/index.js +++ b/benchmarks/index.js @@ -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')); diff --git a/crates/backend/src/ast.rs b/crates/backend/src/ast.rs index e10cf756ddd..d27e1e746b8 100644 --- a/crates/backend/src/ast.rs +++ b/crates/backend/src/ast.rs @@ -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, /// 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 diff --git a/crates/backend/src/codegen.rs b/crates/backend/src/codegen.rs index 9a41621cb1e..11daf2ccc15 100644 --- a/crates/backend/src/codegen.rs +++ b/crates/backend/src/codegen.rs @@ -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) }; diff --git a/crates/cli-support/src/externref.rs b/crates/cli-support/src/externref.rs index be732ceeef0..a7803313541 100644 --- a/crates/cli-support/src/externref.rs +++ b/crates/cli-support/src/externref.rs @@ -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 { /// use to translate the `arg.get` instruction. args: Vec, - /// 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); } diff --git a/crates/cli-support/src/js/mod.rs b/crates/cli-support/src/js/mod.rs index 8450349482d..87042e608fb 100644 --- a/crates/cli-support/src/js/mod.rs +++ b/crates/cli-support/src/js/mod.rs @@ -36,7 +36,7 @@ pub struct Context<'a> { /// renames for each identifier. js_imports: HashMap)>>, - /// 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, /// 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"), diff --git a/crates/cli-support/src/lib.rs b/crates/cli-support/src/lib.rs index 7366bb5acb9..cf37a130616 100755 --- a/crates/cli-support/src/lib.rs +++ b/crates/cli-support/src/lib.rs @@ -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); diff --git a/crates/cli-support/src/multivalue.rs b/crates/cli-support/src/multivalue.rs index f6b8afb078f..a49875381bf 100644 --- a/crates/cli-support/src/multivalue.rs +++ b/crates/cli-support/src/multivalue.rs @@ -30,7 +30,7 @@ pub fn run(module: &mut Module) -> Result<(), Error> { .get_typed::() .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)?; diff --git a/crates/cli-support/src/wasm2es6js.rs b/crates/cli-support/src/wasm2es6js.rs index 77a51d8b445..36298fdd54e 100644 --- a/crates/cli-support/src/wasm2es6js.rs +++ b/crates/cli-support/src/wasm2es6js.rs @@ -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 diff --git a/crates/cli-support/src/wit/incoming.rs b/crates/cli-support/src/wit/incoming.rs index 583c1c34378..73571763834 100644 --- a/crates/cli-support/src/wit/incoming.rs +++ b/crates/cli-support/src/wit/incoming.rs @@ -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(); diff --git a/crates/cli-support/src/wit/mod.rs b/crates/cli-support/src/wit/mod.rs index ca0306967be..fb1825e01d7 100644 --- a/crates/cli-support/src/wit/mod.rs +++ b/crates/cli-support/src/wit/mod.rs @@ -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, - /// All of the wasm module's imported functions. + /// All of the Wasm module's imported functions. function_imports: HashMap, /// A map from the signature of a function in the function table to its adapter, if we've already created it. table_adapters: HashMap, @@ -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} diff --git a/crates/cli-support/src/wit/nonstandard.rs b/crates/cli-support/src/wit/nonstandard.rs index 4a9d5598ff5..5099a72098c 100644 --- a/crates/cli-support/src/wit/nonstandard.rs +++ b/crates/cli-support/src/wit/nonstandard.rs @@ -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` diff --git a/crates/cli-support/src/wit/outgoing.rs b/crates/cli-support/src/wit/outgoing.rs index 033217f61ad..b79a7b68cc6 100644 --- a/crates/cli-support/src/wit/outgoing.rs +++ b/crates/cli-support/src/wit/outgoing.rs @@ -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); diff --git a/crates/cli-support/src/wit/section.rs b/crates/cli-support/src/wit/section.rs index c1e4ce4a896..a534e87ce39 100644 --- a/crates/cli-support/src/wit/section.rs +++ b/crates/cli-support/src/wit/section.rs @@ -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, ); } diff --git a/crates/cli-support/src/wit/standard.rs b/crates/cli-support/src/wit/standard.rs index 0be106f060d..c93c4ef4d3f 100644 --- a/crates/cli-support/src/wit/standard.rs +++ b/crates/cli-support/src/wit/standard.rs @@ -9,7 +9,7 @@ pub struct NonstandardWitSection { /// A list of adapter functions, keyed by their id. pub adapters: HashMap, - /// 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, }, @@ -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. diff --git a/crates/cli/src/bin/wasm-bindgen-test-runner/main.rs b/crates/cli/src/bin/wasm-bindgen-test-runner/main.rs index 26959e9e57f..919702af026 100644 --- a/crates/cli/src/bin/wasm-bindgen-test-runner/main.rs +++ b/crates/cli/src/bin/wasm-bindgen-test-runner/main.rs @@ -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(); diff --git a/crates/cli/src/bin/wasm-bindgen-test-runner/node.rs b/crates/cli/src/bin/wasm-bindgen-test-runner/node.rs index 2bc9f2ae640..ba131cf5465 100644 --- a/crates/cli/src/bin/wasm-bindgen-test-runner/node.rs +++ b/crates/cli/src/bin/wasm-bindgen-test-runner/node.rs @@ -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)); diff --git a/crates/cli/src/bin/wasm-bindgen-test-runner/server.rs b/crates/cli/src/bin/wasm-bindgen-test-runner/server.rs index d0eee0c81d5..f77768c3c61 100644 --- a/crates/cli/src/bin/wasm-bindgen-test-runner/server.rs +++ b/crates/cli/src/bin/wasm-bindgen-test-runner/server.rs @@ -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'); diff --git a/crates/cli/src/bin/wasm-bindgen.rs b/crates/cli/src/bin/wasm-bindgen.rs index ee33c8de036..6076641c138 100644 --- a/crates/cli/src/bin/wasm-bindgen.rs +++ b/crates/cli/src/bin/wasm-bindgen.rs @@ -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] @@ -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 diff --git a/crates/cli/src/bin/wasm2es6js.rs b/crates/cli/src/bin/wasm2es6js.rs index 249faa3a3dd..593dcfb2d11 100644 --- a/crates/cli/src/bin/wasm2es6js.rs +++ b/crates/cli/src/bin/wasm2es6js.rs @@ -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] @@ -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 diff --git a/crates/cli/tests/reference.rs b/crates/cli/tests/reference.rs index a8a39132310..6a4c57956df 100644 --- a/crates/cli/tests/reference.rs +++ b/crates/cli/tests/reference.rs @@ -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 { - // 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() diff --git a/crates/externref-xform/src/lib.rs b/crates/externref-xform/src/lib.rs index df18491889a..7ddf593b2cf 100644 --- a/crates/externref-xform/src/lib.rs +++ b/crates/externref-xform/src/lib.rs @@ -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) diff --git a/crates/futures/src/lib.rs b/crates/futures/src/lib.rs index ba54d7864a1..2c1eb3db6ee 100644 --- a/crates/futures/src/lib.rs +++ b/crates/futures/src/lib.rs @@ -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(future: F) -> Promise where F: Future> + 'static, diff --git a/crates/js-sys/src/lib.rs b/crates/js-sys/src/lib.rs index 829a6246d9b..300eca2d16c 100644 --- a/crates/js-sys/src/lib.rs +++ b/crates/js-sys/src/lib.rs @@ -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 /// diff --git a/crates/macro-support/src/parser.rs b/crates/macro-support/src/parser.rs index bcc4d73932f..338c931c598 100644 --- a/crates/macro-support/src/parser.rs +++ b/crates/macro-support/src/parser.rs @@ -1059,7 +1059,7 @@ impl<'a> MacroParse<(Option, &'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); diff --git a/crates/multi-value-xform/src/lib.rs b/crates/multi-value-xform/src/lib.rs index fe87d32ed46..955cb0d2bfa 100644 --- a/crates/multi-value-xform/src/lib.rs +++ b/crates/multi-value-xform/src/lib.rs @@ -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 diff --git a/crates/test/README.md b/crates/test/README.md index fb7cdc1844e..833d0106758 100644 --- a/crates/test/README.md +++ b/crates/test/README.md @@ -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 diff --git a/crates/test/src/rt/mod.rs b/crates/test/src/rt/mod.rs index 838156155b3..a4343787149 100644 --- a/crates/test/src/rt/mod.rs +++ b/crates/test/src/rt/mod.rs @@ -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. diff --git a/crates/threads-xform/src/lib.rs b/crates/threads-xform/src/lib.rs index 1dd4d70c151..f60a85c14d7 100644 --- a/crates/threads-xform/src/lib.rs +++ b/crates/threads-xform/src/lib.rs @@ -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: diff --git a/crates/wasm-interpreter/src/lib.rs b/crates/wasm-interpreter/src/lib.rs index 61357c1b12c..23729a17e14 100644 --- a/crates/wasm-interpreter/src/lib.rs +++ b/crates/wasm-interpreter/src/lib.rs @@ -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, - // 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, @@ -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, &[]); diff --git a/examples/add/README.md b/examples/add/README.md index dea1f47b08e..17f7d9fa3f0 100644 --- a/examples/add/README.md +++ b/examples/add/README.md @@ -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] diff --git a/examples/console_log/src/lib.rs b/examples/console_log/src/lib.rs index f0e5a4954e2..39bddc57c7a 100644 --- a/examples/console_log/src/lib.rs +++ b/examples/console_log/src/lib.rs @@ -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. diff --git a/examples/deno/README.md b/examples/deno/README.md index 9378700f4f0..2d98e0d01f2 100644 --- a/examples/deno/README.md +++ b/examples/deno/README.md @@ -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. diff --git a/examples/raytrace-parallel/build.py b/examples/raytrace-parallel/build.py index 0e14f490711..c0fc29f8867 100755 --- a/examples/raytrace-parallel/build.py +++ b/examples/raytrace-parallel/build.py @@ -31,7 +31,7 @@ ).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", diff --git a/examples/raytrace-parallel/index.js b/examples/raytrace-parallel/index.js index 4ef286715a9..49529492c35 100644 --- a/examples/raytrace-parallel/index.js +++ b/examples/raytrace-parallel/index.js @@ -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 } diff --git a/examples/raytrace-parallel/src/lib.rs b/examples/raytrace-parallel/src/lib.rs index a08f8aad6b7..91db0906c57 100644 --- a/examples/raytrace-parallel/src/lib.rs +++ b/examples/raytrace-parallel/src/lib.rs @@ -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 diff --git a/examples/raytrace-parallel/src/pool.rs b/examples/raytrace-parallel/src/pool.rs index 7c7118d771c..6a0470d392b 100644 --- a/examples/raytrace-parallel/src/pool.rs +++ b/examples/raytrace-parallel/src/pool.rs @@ -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()); diff --git a/examples/request-animation-frame/src/lib.rs b/examples/request-animation-frame/src/lib.rs index 7cf0dc81979..defd417bb3b 100644 --- a/examples/request-animation-frame/src/lib.rs +++ b/examples/request-animation-frame/src/lib.rs @@ -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 diff --git a/examples/wasm-audio-worklet/build.py b/examples/wasm-audio-worklet/build.py index e2e53d16596..37a93c20db6 100644 --- a/examples/wasm-audio-worklet/build.py +++ b/examples/wasm-audio-worklet/build.py @@ -31,7 +31,7 @@ ).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", diff --git a/examples/wasm-audio-worklet/src/wasm_audio.rs b/examples/wasm-audio-worklet/src/wasm_audio.rs index 5b0534d99b2..55724c96ef2 100644 --- a/examples/wasm-audio-worklet/src/wasm_audio.rs +++ b/examples/wasm-audio-worklet/src/wasm_audio.rs @@ -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( diff --git a/examples/wasm-in-wasm-imports/src/lib.rs b/examples/wasm-in-wasm-imports/src/lib.rs index ed122627bdd..9c03400815a 100644 --- a/examples/wasm-in-wasm-imports/src/lib.rs +++ b/examples/wasm-in-wasm-imports/src/lib.rs @@ -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?; diff --git a/examples/wasm-in-wasm/src/lib.rs b/examples/wasm-in-wasm/src/lib.rs index 6f91b07b683..94c097c520d 100644 --- a/examples/wasm-in-wasm/src/lib.rs +++ b/examples/wasm-in-wasm/src/lib.rs @@ -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()?; diff --git a/examples/wasm-in-web-worker/index.js b/examples/wasm-in-web-worker/index.js index 21c76f79941..05d2209d8e5 100644 --- a/examples/wasm-in-web-worker/index.js +++ b/examples/wasm-in-web-worker/index.js @@ -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(); diff --git a/examples/wasm-in-web-worker/worker.js b/examples/wasm-in-web-worker/worker.js index 3131110b447..99f4d30817b 100644 --- a/examples/wasm-in-web-worker/worker.js +++ b/examples/wasm-in-web-worker/worker.js @@ -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. diff --git a/examples/wasm2js/build.sh b/examples/wasm2js/build.sh index 4c77c30acb4..9ac5332f1a0 100755 --- a/examples/wasm2js/build.sh +++ b/examples/wasm2js/build.sh @@ -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` diff --git a/examples/without-a-bundler-no-modules/src/lib.rs b/examples/without-a-bundler-no-modules/src/lib.rs index 3f365b50825..c927ac0700c 100644 --- a/examples/without-a-bundler-no-modules/src/lib.rs +++ b/examples/without-a-bundler-no-modules/src/lib.rs @@ -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 diff --git a/examples/without-a-bundler/index.html b/examples/without-a-bundler/index.html index 7296030f5c5..4e1655cc871 100644 --- a/examples/without-a-bundler/index.html +++ b/examples/without-a-bundler/index.html @@ -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(); diff --git a/examples/without-a-bundler/src/lib.rs b/examples/without-a-bundler/src/lib.rs index 3f365b50825..c927ac0700c 100644 --- a/examples/without-a-bundler/src/lib.rs +++ b/examples/without-a-bundler/src/lib.rs @@ -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 diff --git a/guide/src/SUMMARY.md b/guide/src/SUMMARY.md index d11123ee764..9ef51ede23a 100644 --- a/guide/src/SUMMARY.md +++ b/guide/src/SUMMARY.md @@ -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) diff --git a/guide/src/contributing/design/describe.md b/guide/src/contributing/design/describe.md index d8684b2f8bc..5cf3a47b47d 100644 --- a/guide/src/contributing/design/describe.md +++ b/guide/src/contributing/design/describe.md @@ -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. diff --git a/guide/src/contributing/design/exporting-rust.md b/guide/src/contributing/design/exporting-rust.md index 58491b34d4a..73149662f1a 100644 --- a/guide/src/contributing/design/exporting-rust.md +++ b/guide/src/contributing/design/exporting-rust.md @@ -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. diff --git a/guide/src/contributing/design/index.md b/guide/src/contributing/design/index.md index 5f353495db7..4f5398279af 100644 --- a/guide/src/contributing/design/index.md +++ b/guide/src/contributing/design/index.md @@ -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 diff --git a/guide/src/contributing/design/js-objects-in-rust.md b/guide/src/contributing/design/js-objects-in-rust.md index 4cc28092324..6e0afcc6a57 100644 --- a/guide/src/contributing/design/js-objects-in-rust.md +++ b/guide/src/contributing/design/js-objects-in-rust.md @@ -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); diff --git a/guide/src/examples/add.md b/guide/src/examples/add.md index 1d3fadd50fb..3c844e85d25 100644 --- a/guide/src/examples/add.md +++ b/guide/src/examples/add.md @@ -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 diff --git a/guide/src/examples/raytrace.md b/guide/src/examples/raytrace.md index 522a2f70b96..2e012190d16 100644 --- a/guide/src/examples/raytrace.md +++ b/guide/src/examples/raytrace.md @@ -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 diff --git a/guide/src/examples/web-audio.md b/guide/src/examples/web-audio.md index ed41f7a0403..8785fdb800b 100644 --- a/guide/src/examples/web-audio.md +++ b/guide/src/examples/web-audio.md @@ -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}} diff --git a/guide/src/introduction.md b/guide/src/introduction.md index a2f1592b92b..c9ffdc15bf9 100644 --- a/guide/src/introduction.md +++ b/guide/src/introduction.md @@ -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 diff --git a/guide/src/reference/attributes/on-js-imports/catch.md b/guide/src/reference/attributes/on-js-imports/catch.md index 07c15d2646d..7ec9e6dcc56 100644 --- a/guide/src/reference/attributes/on-js-imports/catch.md +++ b/guide/src/reference/attributes/on-js-imports/catch.md @@ -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! diff --git a/guide/src/reference/attributes/on-js-imports/final.md b/guide/src/reference/attributes/on-js-imports/final.md index a3e65b04c67..e912a50fad3 100644 --- a/guide/src/reference/attributes/on-js-imports/final.md +++ b/guide/src/reference/attributes/on-js-imports/final.md @@ -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: diff --git a/guide/src/reference/attributes/on-js-imports/raw_module.md b/guide/src/reference/attributes/on-js-imports/raw_module.md index 1f8da2f3dfb..0a1f82f9572 100644 --- a/guide/src/reference/attributes/on-js-imports/raw_module.md +++ b/guide/src/reference/attributes/on-js-imports/raw_module.md @@ -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. diff --git a/guide/src/reference/attributes/on-js-imports/variadic.md b/guide/src/reference/attributes/on-js-imports/variadic.md index 31cec10a12d..af6c56994e9 100644 --- a/guide/src/reference/attributes/on-js-imports/variadic.md +++ b/guide/src/reference/attributes/on-js-imports/variadic.md @@ -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 diff --git a/guide/src/reference/attributes/on-rust-exports/start.md b/guide/src/reference/attributes/on-rust-exports/start.md index b3b583cb5f2..1d05196bc61 100644 --- a/guide/src/reference/attributes/on-rust-exports/start.md +++ b/guide/src/reference/attributes/on-rust-exports/start.md @@ -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 diff --git a/guide/src/reference/browser-support.md b/guide/src/reference/browser-support.md index f2a05cad3f9..aa43c644ade 100644 --- a/guide/src/reference/browser-support.md +++ b/guide/src/reference/browser-support.md @@ -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! diff --git a/guide/src/reference/cli.md b/guide/src/reference/cli.md index f7377ae7abf..ad300bdca5e 100644 --- a/guide/src/reference/cli.md +++ b/guide/src/reference/cli.md @@ -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` diff --git a/guide/src/reference/deployment.md b/guide/src/reference/deployment.md index aa66e8d6f65..fd6f5f23390 100644 --- a/guide/src/reference/deployment.md +++ b/guide/src/reference/deployment.md @@ -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, diff --git a/guide/src/reference/optimize-size.md b/guide/src/reference/optimize-size.md index 6f869ffd88b..8a9c26836cc 100644 --- a/guide/src/reference/optimize-size.md +++ b/guide/src/reference/optimize-size.md @@ -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 diff --git a/guide/src/reference/reference-types.md b/guide/src/reference/reference-types.md index 82edeea6fb9..c5315d6a97e 100644 --- a/guide/src/reference/reference-types.md +++ b/guide/src/reference/reference-types.md @@ -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 diff --git a/guide/src/reference/types/result.md b/guide/src/reference/types/result.md index 8e9b880aaaf..029fcdcaf4f 100644 --- a/guide/src/reference/types/result.md +++ b/guide/src/reference/types/result.md @@ -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 diff --git a/guide/src/wasm-bindgen-test/continuous-integration.md b/guide/src/wasm-bindgen-test/continuous-integration.md index 9e8823d9cc5..aa56dc1e295 100644 --- a/guide/src/wasm-bindgen-test/continuous-integration.md +++ b/guide/src/wasm-bindgen-test/continuous-integration.md @@ -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 diff --git a/guide/src/wasm-bindgen-test/index.md b/guide/src/wasm-bindgen-test/index.md index 3667d7f7a04..010fe6ee2af 100644 --- a/guide/src/wasm-bindgen-test/index.md +++ b/guide/src/wasm-bindgen-test/index.md @@ -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 diff --git a/releases/release-announcement-template.md b/releases/release-announcement-template.md index a1feaf4b684..56757241ff2 100644 --- a/releases/release-announcement-template.md +++ b/releases/release-announcement-template.md @@ -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][] diff --git a/src/convert/impls.rs b/src/convert/impls.rs index fd77ce88f8f..e54f0669c5a 100644 --- a/src/convert/impls.rs +++ b/src/convert/impls.rs @@ -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"), diff --git a/src/convert/slices.rs b/src/convert/slices.rs index 99adc9b3745..45ec69bcb5d 100644 --- a/src/convert/slices.rs +++ b/src/convert/slices.rs @@ -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); diff --git a/src/convert/traits.rs b/src/convert/traits.rs index ca2441d5f02..d13929e6b31 100644 --- a/src/convert/traits.rs +++ b/src/convert/traits.rs @@ -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 diff --git a/src/lib.rs b/src/lib.rs index 8c512d882a1..aa1e7c897f1 100644 --- a/src/lib.rs +++ b/src/lib.rs @@ -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()) }