[docs] Consistently capitalize Wasm when referring to it in the docs.…

… NFC (#20266)

docs/emcc.txt

@@ -80,12 +80,12 @@ Options that are modified or new in *emcc* are listed below:
 
 "-Os"
    [compile+link] Like "-O3", but focuses more on code size (and may
-   make tradeoffs with speed). This can affect both wasm and
+   make tradeoffs with speed). This can affect both Wasm and
    JavaScript.
 
 "-Oz"
    [compile+link] Like "-Os", but reduces code size even further, and
-   may take longer to run. This can affect both wasm and JavaScript.
+   may take longer to run. This can affect both Wasm and JavaScript.
 
    Note:
 
@@ -166,7 +166,7 @@ Options that are modified or new in *emcc* are listed below:
    Preserve debug information, but in a separate file on the side.
    This is the same as "-g", but the main file will contain no debug
    info. Instead, debug info will be present in a file on the side, in
-   "FILENAME" if provided, otherwise the same as the wasm file but
+   "FILENAME" if provided, otherwise the same as the Wasm file but
    with suffix ".debug.wasm". While the main file contains no debug
    info, it does contain a URL to where the debug file is, so that
    devtools can find it. You can use "-sSEPARATE_DWARF_URL=URL" to
@@ -180,7 +180,7 @@ Options that are modified or new in *emcc* are listed below:
    file is updated to have a "sourceMappingURL" section. The resulting
    URL will have format: "<base-url>" + "<wasm-file-name>" + ".map".
    "<base-url>" defaults to being empty (which means the source map is
-   served from the same directory as the wasm file). It can be changed
+   served from the same directory as the Wasm file). It can be changed
    using --source-map-base.
 
 "-g<level>"
@@ -221,7 +221,7 @@ Options that are modified or new in *emcc* are listed below:
    to the compiler.
 
 "--emit-symbol-map"
-   [link] Save a map file between function indexes in the wasm and
+   [link] Save a map file between function indexes in the Wasm and
    function names. By storing the names on a file on the side, you can
    avoid shipping the names, and can still reconstruct meaningful
    stack traces by translating the indexes back to the names.
@@ -487,8 +487,8 @@ Options that are modified or new in *emcc* are listed below:
 
       Note:
 
-        Note that this is only relevant when *not* emitting wasm, as
-        wasm embeds the memory init data in the wasm binary.
+        Note that this is only relevant when *not* emitting Wasm, as
+        Wasm embeds the memory init data in the Wasm binary.
 
    Possible values are:
 
@@ -594,7 +594,7 @@ Options that are modified or new in *emcc* are listed below:
         WebAssembly).
 
       * <name> **.wasm** : WebAssembly without JavaScript support code
-        ("standalone wasm"; this enables "STANDALONE_WASM").
+        ("standalone Wasm"; this enables "STANDALONE_WASM").
 
    These rules only apply when linking.  When compiling to object code
    (See *-c* below) the name of the output file is irrelevant.

docs/packaging.md

@@ -55,8 +55,7 @@ To see how our CI builds things, the relevant script is
 In general, the repos you need to build are LLVM and Binaryen (as emscripten
 itself doesn't have any binaries to build).
 
-When packaging build results, you need the following executables (when using
-the wasm backend):
+When packaging build results, you need the following executables:
 
   * From LLVM:
     * clang

site/source/docs/api_reference/emscripten.h.rst

@@ -1385,10 +1385,10 @@ IndexedDB
   :param perror: An out parameter that will be filled with a non-zero value if an error occurred.
 
 
-Upstream Asyncify functions
-===========================
+Asyncify functions
+==================
 
-These functions only work with the upstream wasm backend when using Asyncify.
+These functions only work when using Asyncify.
 
 Typedefs
 --------
@@ -1408,18 +1408,18 @@ Functions
 .. c:function:: void emscripten_scan_stack(em_scan_func func)
 
     Scan the C userspace stack, which means the stack managed by the compiled
-    code (as opposed to the wasm VM's internal stack, which is not directly
+    code (as opposed to the Wasm VM's internal stack, which is not directly
     observable). This data is already in linear memory; this function just
     gives you a simple way to know where it is.
 
 .. c:function:: void emscripten_scan_registers(em_scan_func func)
 
-    Scan "registers", by which we mean data that is not in memory. In wasm,
+    Scan "registers", by which we mean data that is not in memory. In Wasm,
     that means data stored in locals, including locals in functions higher up
-    the stack - the wasm VM has spilled them, but none of that is observable to
+    the stack - the Wasm VM has spilled them, but none of that is observable to
     user code).
 
-    Note that this function scans wasm locals. Depending on the LLVM
+    Note that this function scans Wasm locals. Depending on the LLVM
     optimization level, this may not scan the original locals in your source
     code. For example in ``-O0`` locals may be stored on the stack. To make
     sure you scan everything necessary, you can also do
@@ -1431,15 +1431,15 @@ Functions
 
 .. c:function:: void emscripten_lazy_load_code()
 
-    This creates two wasm files at compile time: the first wasm which is
+    This creates two Wasm files at compile time: the first Wasm which is
     downloaded and run normally, and a second that is lazy-loaded. When an
-    ``emscripten_lazy_load_code()`` call is reached, we load the second wasm
+    ``emscripten_lazy_load_code()`` call is reached, we load the second Wasm
     and resume execution using it.
 
     The idea here is that the initial download can be quite small, if you
     place enough ``emscripten_lazy_load_code()`` calls in your codebase, as
-    the optimizer can remove code from the first wasm if it sees it can't
-    be reached. The second downloaded wasm can contain your full codebase,
+    the optimizer can remove code from the first Wasm if it sees it can't
+    be reached. The second downloaded Wasm can contain your full codebase,
     including rarely-used functions, in which case the lazy-loading may
     not happen at all.
 
@@ -1456,8 +1456,8 @@ Emscripten runtime JS code, or run Emscripten binaries in your own runtime.
 .. c:function:: void emscripten_notify_memory_growth(i32 index)
 
     Called when memory has grown. In a JS runtime, this is used to know when
-    to update the JS views on the wasm memory, which otherwise we would need
-    to constantly check for after any wasm code runs. See
+    to update the JS views on the Wasm memory, which otherwise we would need
+    to constantly check for after any Wasm code runs. See
     `this wasi discussion <https://github.com/WebAssembly/WASI/issues/82>`_.
 
     :param i32 index: Which memory has grown.

site/source/docs/api_reference/module.rst

@@ -111,7 +111,7 @@ The following ``Module`` attributes affect code execution. Set them to customize
 
 .. js:attribute:: Module.onAbort
 
-  If set, this function is called when abnormal program termination occurs. That can happen due to the C method ``abort()`` being called directly, or called from JavaScript, or due to a fatal problem such as being unable to fetch a necessary file during startup (like the wasm binary when running wasm), etc. After calling this function, program termination occurs (i.e., you can't use this to try to do something else instead of stopping; there is no possibility of recovering here).
+  If set, this function is called when abnormal program termination occurs. That can happen due to the C method ``abort()`` being called directly, or called from JavaScript, or due to a fatal problem such as being unable to fetch a necessary file during startup (such as the Wasm binary), etc. After calling this function, program termination occurs (i.e., you can't use this to try to do something else instead of stopping; there is no possibility of recovering here).
 
 .. js:attribute:: Module.onRuntimeInitialized
 

site/source/docs/api_reference/wasm_workers.rst

@@ -18,7 +18,7 @@ Quick Example
 
   void run_in_worker()
   {
-    printf("Hello from wasm worker!\n");
+    printf("Hello from Wasm Worker!\n");
   }
 
   int main()

site/source/docs/building_from_source/index.rst

@@ -14,8 +14,8 @@ Get the ``main`` branches, or check the `Packaging <https://github.com/emscripte
 Building LLVM
 -------------
 
-For using the LLVM wasm backend (recommended), simply build normal upstream LLVM from the `monorepo <https://github.com/llvm/llvm-project>`_.
-Include clang and wasm-ld (using something like ``-DLLVM_ENABLE_PROJECTS='lld;clang'``) and the wasm backend (which is included by default; just don't disable it), following `that project's instructions <http://llvm.org/docs/CMake.html>`_.
+Build LLVM from the `git repo <https://github.com/llvm/llvm-project>`_.
+Include clang and wasm-ld (using something like ``-DLLVM_ENABLE_PROJECTS='lld;clang'``) and the Wasm backend (which is included by default; just don't disable it), following `that project's instructions <http://llvm.org/docs/CMake.html>`_.
 For example, something like this can work:
 
   ::

site/source/docs/compiling/Building-Projects.rst

@@ -30,7 +30,7 @@ To build with Emscripten, you would instead use the following commands:
   # Run emconfigure with the normal configure command as an argument.
   emconfigure ./configure
 
-  # Run emmake with the normal make to generate wasm object files.
+  # Run emmake with the normal make to generate Wasm object files.
   emmake make
 
   # Compile the linked code generated by make to JavaScript + WebAssembly.
@@ -48,8 +48,8 @@ To build with Emscripten, you would instead use the following commands:
 
 .. tip:: We recommend you call both *emconfigure* and *emmake* scripts in *configure*- and *CMake*-based build systems. Whether you actually **need** to call both tools depends on the build system (some systems will store the environment variables in the configure step, and others will not).
 
-*Make* generates wasm object files. It may also link the object files into
-libraries and/or wasm executables. Unless such a build system has been modified
+*Make* generates Wasm object files. It may also link the object files into
+libraries and/or Wasm executables. Unless such a build system has been modified
 to also emit JavaScript output, you will need to run an additional ``emcc``
 command as shown above, that will emit the final runnable JavaScript and
 WebAssembly.
@@ -61,15 +61,15 @@ WebAssembly.
   file extensions are the same as *gcc* would use for the different types).
   Irrespective of the file extension, these files contain something that *emcc*
   can compile into the final JavaScript + WebAssembly (typically the contents
-  will be wasm object files, but if you build with LTO then they will contain
+  will be Wasm object files, but if you build with LTO then they will contain
   LLVM bitcode).
 
 .. note::
 
-  Some build systems may not properly emit wasm object files using the above procedure,
+  Some build systems may not properly emit Wasm object files using the above procedure,
   and you may see ``is not a valid input file`` warnings. You can run ``file`` to
   check what a file contains (also you can manually check if the contents
-  start with ``\0asm`` to see if they are wasm object files, or ``BC`` if they
+  start with ``\0asm`` to see if they are Wasm object files, or ``BC`` if they
   are LLVM bitcode). It is also worth running ``emmake make VERBOSE=1`` which
   will print out the commands it runs - you should see *emcc* being used, and
   not the native system compiler. If *emcc* is not used, you may need to modify
@@ -178,7 +178,7 @@ must specify :ref:`-g <emcc-g>` or one of the
 
 .. code-block:: bash
 
-  # Compile the wasm object file to JavaScript+WebAssembly, with debug info
+  # Compile the Wasm object file to JavaScript+WebAssembly, with debug info
   # -g or -gN can be used to set the debug level (N)
   emcc -g project.o -o project.js
 
@@ -406,4 +406,4 @@ Troubleshooting
   .. note:: You can use ``llvm-nm`` to see which symbols are defined in each object file.
 
   One solution is to use :ref:`dynamic-linking <Dynamic-Linking>`. This ensures that libraries are linked only once, in the final build stage.
-- When generating standalone wasm, make sure to invoke the ``_start`` or (for ``--no-entry``) ``_initialize`` export before attempting to use the module.
+- When generating standalone Wasm, make sure to invoke the ``_start`` or (for ``--no-entry``) ``_initialize`` export before attempting to use the module.

site/source/docs/compiling/WebAssembly.rst

@@ -20,31 +20,31 @@ WebAssembly is emitted by default, without the need for any special flags.
       emcc [..args..] -sWASM=0
 
 .. note:: Emscripten's WebAssembly support depends on `Binaryen <https://github.com/WebAssembly/binaryen>`_, which is provided by the emsdk (if you don't use the emsdk, you need to build it and set it up in your ``.emscripten`` file).
-.. note:: Deciding to compile to wasm or JS can be done at the linking stage: it doesn't affect the object files.
+.. note:: Deciding to compile to Wasm or JS can be done at the linking stage: it doesn't affect the object files.
 
 Backends
 --------
 
-Emscripten emits WebAssembly using the **upstream LLVM wasm backend**, since
+Emscripten emits WebAssembly using the **upstream LLVM Wasm backend**, since
 version ``1.39.0`` (October 2019). Previously emscripten also supported the
 old **fastcomp** backend which was removed in ``2.0.0`` (August 2020).
 
 There are some differences you may notice between the two backends, if you
 upgrade from fastcomp to upstream:
 
-* The wasm backend is strict about linking files with different features sets -
+* The Wasm backend is strict about linking files with different features sets -
   for example, if one file was built with atomics but another was not, it will
   error at link time. This prevents possible bugs, but may mean you need to make
   some build system fixes.
 
 * ``WASM=0`` behaves differently in the two backends. In fastcomp we emit
-  asm.js, while in upstream we emit JS (since not all wasm constructs can be
+  asm.js, while in upstream we emit JS (since not all Wasm constructs can be
   expressed in asm.js). Also, the JS support implements the same external
-  ``WebAssembly.*`` API, so in particular startup will be async just like wasm
+  ``WebAssembly.*`` API, so in particular startup will be async just like Wasm
   by default, and you can control that with ``WASM_ASYNC_COMPILATION`` (even
   though ``WASM=0``).
 
-* The wasm backend uses wasm object files by default. That means that it does
+* The Wasm backend uses Wasm object files by default. That means that it does
   codegen at the compile step, which makes the link step much faster - like a
   normal native compiler. For comparison, in fastcomp the compile step emits
   LLVM IR in object files.
@@ -67,22 +67,22 @@ upgrade from fastcomp to upstream:
     perform some minor types of link time optimization even without LTO being
     set. The LLVM backend requires actually setting LTO for those things.
 
-* `wasm-ld`, the linker used by the wasm backend, requires libraries (`.a`
+* `wasm-ld`, the linker used by the Wasm backend, requires libraries (`.a`
   archives) to contain symbol indexes.  This matches the behaviour the native
   GNU linker.  While `emar` will create such indexes by default, native tools
   such as GNU `ar` and GNU `strip` are not aware of the WebAssembly object
   format and cannot create archive indexes.  In particular, if you run GNU
   `strip` on an archive file that contains WebAssembly object files it will
   remove the index which makes the archive unusable at link time.
 
-* Also see the `blocker bugs on the wasm backend <https://github.com/emscripten-core/emscripten/projects/1>`_, and the `wasm backend tagged issues <https://github.com/emscripten-core/emscripten/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3A"LLVM+wasm+backend">`_.
+* Also see the `blocker bugs on the Wasm backend <https://github.com/emscripten-core/emscripten/projects/1>`_, and the `Wasm backend tagged issues <https://github.com/emscripten-core/emscripten/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3A"LLVM+wasm+backend">`_.
 
 Trapping
 ========
 
 WebAssembly can trap - throw an exception - on things like division by zero, rounding a very large float to an int, and so forth. In asm.js such things were silently ignored, as in JavaScript they do not throw, so this is a difference between JavaScript and WebAssembly that you may notice, with the browser reporting an error like ``float unrepresentable in integer range``, ``integer result unrepresentable``, ``integer overflow``, or ``Out of bounds Trunc operation``.
 
-The LLVM wasm backend avoids traps by adding more code around each possible trap (basically clamping the value if it would trap). This can increase code size and decrease speed, if you don't need that extra code. The proper solution for this is to use newer wasm instructions that do not trap, by calling emcc or clang with ``-mnontrapping-fptoint``. That code may not run in older VMs, though.
+The LLVM Wasm backend avoids traps by adding more code around each possible trap (basically clamping the value if it would trap). This can increase code size and decrease speed, if you don't need that extra code. The proper solution for this is to use newer Wasm instructions that do not trap, by calling emcc or clang with ``-mnontrapping-fptoint``. That code may not run in older VMs, though.
 
 Compiler output
 ===============
@@ -112,7 +112,7 @@ Another noticeable effect is that WebAssembly is compiled asynchronously by defa
 Web server setup
 ================
 
-To serve wasm in the most efficient way over the network, make sure your web server has the proper MIME type for ``.wasm`` files, which is application/wasm. That will allow streaming compilation, where the browser can start to compile code as it downloads.
+To serve Wasm in the most efficient way over the network, make sure your web server has the proper MIME type for ``.wasm`` files, which is application/wasm. That will allow streaming compilation, where the browser can start to compile code as it downloads.
 
 In Apache, you can do this with
 

site/source/docs/contributing/developers_guide.rst

@@ -79,12 +79,12 @@ The :ref:`Emscripten Compiler Frontend (emcc) <emccdoc>` is a python script that
   builds and integrates with the Emscripten system libraries, both the
   compiled ones and the ones implemented in JS.
 - **emcc** then calls `emscripten.py <https://github.com/emscripten-core/emscripten/blob/main/emscripten.py>`_
-  which performs the final transformation to wasm (including invoking
+  which performs the final transformation to Wasm (including invoking
   **wasm-emscripten-finalize** from Binaryen) and calls the JS compiler
   (see ``src/compiler.js`` and related files) which emits the JS.
-- If optimizing wasm, **emcc** will then call **wasm-opt**, run meta-dce, and
+- If optimizing Wasm, **emcc** will then call **wasm-opt**, run meta-dce, and
   other useful things. It will also run JS optimizations on the JS that is
-  emitted alongside the wasm.
+  emitted alongside the Wasm.
 
 Emscripten Test Suite
 =====================