[docs] Remove some fastcomp mentions (#12547)

docs/emcc.txt

@@ -565,9 +565,8 @@ Options that are modified or new in *emcc* are listed below:
 
       * <name> **.bc** : LLVM bitcode.
 
-      * <name> **.o** : WebAssembly object file (unless fastcomp or
-        -flto is used in which case it will be in LLVM bitcode
-        format).
+      * <name> **.o** : WebAssembly object file (unless -flto is used
+        in which case it will be in LLVM bitcode format).
 
       * <name> **.wasm** : WebAssembly without JavaScript support code
         ("standalone wasm"; this enables "STANDALONE_WASM").

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

@@ -1337,43 +1337,6 @@ IndexedDB
   :param perror: An out parameter that will be filled with a non-zero value if an error occurred.
 
 
-Fastcomp Asyncify functions
-===========================
-
-Fastcomp's Asyncify support has asynchronous functions that appear synchronously in C, the linker flag `-s ASYNCIFY=1` is required to use these functions. See `Asyncify <https://emscripten.org/docs/porting/asyncify.html>`_ for more details.
-
-Typedefs
---------
-
-.. c:type:: emscripten_coroutine
-
-    A handle to the structure used by coroutine supporting functions.
-
-Functions
----------
-
-.. c:function:: void emscripten_sleep_with_yield(unsigned int ms)
-
-  Sleep for `ms` milliseconds, while allowing other asynchronous operations, e.g. caused by ``emscripten_async_call``, to run normally, during
-  this sleep. Note that this method **does** still block the main loop, as otherwise it could recurse, if you are calling this method from it.
-  Even so, you should use this method carefully: the order of execution is potentially very confusing this way.
-
-  .. note:: This only works in fastcomp. In the wasm backend, just use sleep, which does not have strict yield checking.
-
-.. c:function:: emscripten_coroutine emscripten_coroutine_create(em_arg_callback_func func, void *arg, int stack_size)
-
-    Create a coroutine which will be run as `func(arg)`.
-
-    :param int stack_size: the stack size that should be allocated for the coroutine, use 0 for the default value.
-
-.. c:function:: int emscripten_coroutine_next(emscripten_coroutine coroutine)
-
-    Run `coroutine` until it returns, or `emscripten_yield` is called. A non-zero value is returned if `emscripten_yield` is called, otherwise 0 is returned, and future calls of `emscripten_coroutine_next` on this coroutine is undefined behaviour.
-
-.. c:function:: void emscripten_yield(void)
-
-    This function should only be called in a coroutine created by `emscripten_coroutine_create`, when it called, the coroutine is paused and the caller will continue.
-
 Upstream Asyncify functions
 ===========================
 

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

@@ -6,7 +6,10 @@ fiber.h
 
 `Fibers <https://en.wikipedia.org/wiki/Fiber_(computer_science)>`_ are light, co-operative threads of execution. The `fiber.h <https://github.com/emscripten-core/emscripten/blob/master/system/include/emscripten/fiber.h>`_ header defines a low-level API for manipulating Fibers in Emscripten. Fibers are implemented with :ref:`Asyncify`, so you must link your program with ``-s ASYNCIFY`` if you intend to use them.
 
-Fibers are intended as a building block for asynchronous control flow constructs, such as coroutines. They supersede the legacy coroutine API available in the fastcomp backend. This API is similar to, but distinct from, POSIX `ucontext <https://en.wikipedia.org/wiki/Setcontext>`_.
+Fibers are intended as a building block for asynchronous control flow constructs,
+such as coroutines. They supersede the legacy coroutine API that was available
+in the fastcomp backend. This API is similar to, but distinct from, POSIX
+`ucontext <https://en.wikipedia.org/wiki/Setcontext>`_.
 
 .. contents:: Table of Contents
     :local:

site/source/docs/compiling/WebAssembly.rst

@@ -29,10 +29,8 @@ Backends
 --------
 
 Emscripten emits WebAssembly using the **upstream LLVM wasm backend**, since
-version ``1.39.0`` (October 2019), and the old **fastcomp** backend is
-deprecated (you can still use the deprecated fastcomp backend by getting
-``latest-fastcomp`` instead of the normal ``latest``, or ``1.39.0-fastcomp``
-instead of ``1.39.0``, etc.).
+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:

site/source/docs/debugging/Sanitizers.rst

@@ -4,14 +4,6 @@
 Debugging with Sanitizers
 =========================
 
-.. warning::
-
-  Sanitizers can only be used with the upstream wasm backend. If you are
-  using fastcomp, you need to upgrade before sanitizers will work.
-  See here__ for instructions.
-
-__ https://v8.dev/blog/emscripten-llvm-wasm#testing
-
 .. _sanitizer_ubsan:
 
 Undefined Behaviour Sanitizer

site/source/docs/getting_started/FAQ.rst

@@ -101,8 +101,15 @@ Otherwise, to debug this, look for an error reported on the page itself, or in t
 What is "No WebAssembly support found. Build with -s WASM=0 to target JavaScript instead" or "no native wasm support detected"?
 ===============================================================================================================================
 
-Those errors indicate that WebAssembly support is not present in the VM you are trying to run the code in. Compile with ``-s WASM=0`` to disable WebAssembly (and emit asm.js instead) if you want your code to run in such environments (all modern browsers support WebAssembly, but in some cases you may want to reach 100% of browsers, including legacy ones).
+Those errors indicate that WebAssembly support is not present in the VM you are
+trying to run the code in. Compile with ``-s WASM=0`` to disable WebAssembly
+(and emit equivalent JS instead), if you want your code to run in such
+environments. Note that all modern browsers support WebAssembly, so this should
+only matter if you need to target legacy browsers.
 
+``-s WASM=0`` output should run exactly the same as a WebAssembly build, but may
+be larger, start up slower, and run slower, so it's better to ship WebAssembly
+whenever you can.
 
 Why do I get ``machine type must be wasm32`` or ``is not a valid input file`` during linking?
 =============================================================================================

site/source/docs/getting_started/Tutorial.rst

@@ -20,7 +20,10 @@ For the next section you will need to open a command prompt:
 - On Linux or macOS, open a *Terminal*.
 - On Windows open the :ref:`Emscripten Command Prompt <emcmdprompt>`, a command prompt that has been pre-configured with the correct system paths and settings to point to the :term:`active <Active Tool/SDK>` Emscripten tools. To access this prompt, type **Emscripten** in the Windows 8 start screen, and then select the **Emscripten Command Prompt** option.
 
-Navigate with the command prompt to the emscripten directory under the SDK. This is a folder below the :term:`emsdk root directory`, typically **<emsdk root directory>/fastcomp/emscripten/** (for the older "fastcomp" compiler; for the newer upstream LLVM wasm backend it will be **<emsdk root directory>/upstream/emscripten/**). The examples below will depend on finding files relative to that location.
+Navigate with the command prompt to the emscripten directory under the SDK. This
+is a folder below the :term:`emsdk root directory`, typically
+**<emsdk root directory>/upstream/emscripten/**.
+The examples below will depend on finding files relative to that location.
 
 .. note:: In older emscripten versions the directory structure was different: the version number appeared, and the backend (fastcomp/upstream) did not, so you would use something like **<emsdk root directory>/emscripten/1.20.0/**.
 

site/source/docs/getting_started/downloads.rst

@@ -77,26 +77,13 @@ You can also install a specific version by specifying it, for example,
 
 .. note:: When installing old versions from before the build infrastructure rewrite (anything before ``1.38.33``), you need to write something like ``./emsdk install sdk-1.38.20-64bit`` (add ``sdk-`` and ``-64bit``) as that was the naming convention at the time.
 
-You can also specify which backend you want to use, either ``fastcomp`` or ``upstream`` (without specifying the backend, the current default is used), for example,
-
-  ::
-
-    # Get a specific version using the upstream backend.
-    ./emsdk install latest-upstream
-
-    # Get a specific version using the fastcomp backend.
-    ./emsdk install 1.38.45-fastcomp
-
 
 There are also "tip-of-tree builds", which are the very latest code that passes integration tests on `Chromium CI <https://ci.chromium.org/p/emscripten-releases>`_. This is updated much more frequently than tagged releases, but may be less stable (we `tag releases manually <https://github.com/emscripten-core/emscripten/blob/master/docs/process.md#minor-version-updates-1xy-to-1xy1>`_ using a more careful procedure). Tip-of-tree builds may be useful for continuous integration that uses the emsdk (as Emscripten's GitHub CI does), and you may want to use it in your own CI as well, so that if you find a regression on your project you can report it and prevent it from reaching a tagged release. Tip-of-builds may also be useful if you want to test a feature that just landed but didn't reach a release yet. To use a tip-of-tree build, use the ``tot`` target, and note that you must specify the backend explicitly,
 
   ::
 
-    # Get a tip-of-tree using the upstream backend.
-    ./emsdk install tot-upstream
-
-    # Get a tip-of-tree using the fastcomp backend.
-    ./emsdk install tot-fastcomp
+    # Get a tip-of-tree 
+    ./emsdk install tot
 
 (In the above examples we installed the various targets; remember to also ``activate`` them as in the full example from earlier.)
 

site/source/docs/porting/asyncify.rst

@@ -22,12 +22,6 @@ See the
 for general background and details of how it works internally. The following
 expands on the Emscripten examples from that post.
 
-.. note:: This post talks about Asyncify using the new LLVM wasm backend.
-          There was an older Asyncify implementation for the old fastcomp
-          backend. The two algorithms and implementations are entirely separate,
-          so if you are using fastcomp, these docs may not be accurate - you
-          should upgrade to the wasm backend and new Asyncify!
-
 .. _yielding_to_main_loop:
 
 Sleeping / yielding to the event loop

site/source/docs/tools_reference/emcc.rst

@@ -441,7 +441,7 @@ Options that are modified or new in *emcc* are listed below:
     - <name> **.mjs** : ES6 JavaScript module (+ separate **<name>.wasm** file if emitting WebAssembly).
     - <name> **.html** : HTML + separate JavaScript file (**<name>.js**; + separate **<name>.wasm** file if emitting WebAssembly).
     - <name> **.bc** : LLVM bitcode.
-    - <name> **.o** : WebAssembly object file (unless fastcomp or -flto is used in which case it will be in LLVM bitcode format).
+    - <name> **.o** : WebAssembly object file (unless -flto is used in which case it will be in LLVM bitcode format).
     - <name> **.wasm** : WebAssembly without JavaScript support code ("standalone wasm"; this enables ``STANDALONE_WASM``).
 
   .. note:: If ``--memory-init-file`` is used, a **.mem** file will be created in addition to the generated **.js** and/or **.html** file.

site/source/docs/tools_reference/emsdk.rst

@@ -89,7 +89,8 @@ won't conflict with any config file the user might have in their home directory.
 
 The file should generally not be updated directly unless you're :ref:`building Emscripten from source <installing-from-source>`. Instead use the *emsdk* to activate specific SDKs and tools as needed (``emsdk activate <tool/SDK>``).
 
-Below are typical **.emscripten** files created by *emsdk*. Note the variable names used to point to the different tools::
+Below are examples of possible **.emscripten** files created by *emsdk*. Note
+the variable names used to point to the different tools::
 
   # .emscripten file from Windows SDK
 
@@ -104,7 +105,7 @@ Below are typical **.emscripten** files created by *emsdk*. Note the variable na
 
   import os
   NODE_JS = 'nodejs'
-  LLVM_ROOT='/home/ubuntu/emsdk_portable/clang/fastcomp/build_incoming_64/bin'
+  LLVM_ROOT='/home/ubuntu/emsdk/upstream/bin'
 
 .. _emsdk_howto: