Merge remote-tracking branch 'upstream/main' into openal-alext-support

Author: gabeklavans

.circleci/config.yml

@@ -112,7 +112,7 @@ commands:
     description: "install canary version of node"
     steps:
       - install-node-version:
-         node_version: "22.0.0-v8-canary20231108ff311d5a39"
+         node_version: "22.0.0-v8-canary20240423a2eb2005bd"
          canary: true
   install-v8:
     description: "install v8 using jsvu"
@@ -318,6 +318,7 @@ commands:
             # PIC version of libSDL which is used by test_sdl2_misc_main_module
             export EM_FROZEN_CACHE=""
             test/runner << parameters.test_targets >>
+      - upload-test-results
   setup-macos:
     steps:
       - run:
@@ -367,6 +368,7 @@ commands:
             # TODO: Do GL testing when https://bugzil.la/1375585 (lack of WebGL
             #       support in headless mode) resolves
             EMTEST_LACKS_GRAPHICS_HARDWARE: "1"
+            EMTEST_LACKS_WEBGPU: "1"
             EMTEST_LACKS_SOUND_HARDWARE: "1"
             # OffscreenCanvas support is not yet done in Firefox.
             EMTEST_LACKS_OFFSCREEN_CANVAS: "1"
@@ -720,6 +722,7 @@ jobs:
           test_targets: "
             core0.test_hello_argc
             core2.test_demangle_stacks_symbol_map"
+      - upload-test-results
   test-node-compat:
     # We don't use `bionic` here since its too old to run recent node versions:
     # `/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found`
@@ -759,7 +762,8 @@ jobs:
             other.test_js_optimizer_verbose
             other.test_node_unhandled_rejection
             other.test_full_js_library*
-            core2.test_hello_world"
+            core2.test_hello_world
+            core2.test_fs_write_rawfs"
       # Run a few test with the most recent version of node
       # In particular we have some tests that require node flags on older
       # versions of node but not with the most recent version.
@@ -794,6 +798,8 @@ jobs:
           test_targets: "other skip:other.test_native_link_error_message"
   test-browser-chrome:
     executor: bionic
+    environment:
+      EMTEST_LACKS_WEBGPU: "1"
     steps:
       - run-tests-chrome:
           title: "browser"
@@ -803,19 +809,24 @@ jobs:
             "
   test-browser-chrome-wasm64:
     executor: bionic
+    environment:
+      EMTEST_LACKS_WEBGPU: "1"
     steps:
       - run-tests-chrome:
           title: "browser64"
           test_targets: "browser64"
   test-browser-chrome-2gb:
     executor: bionic
+    environment:
+      EMTEST_LACKS_WEBGPU: "1"
     steps:
       - run-tests-chrome:
           title: "browser_2gb"
           test_targets: "browser_2gb"
   test-browser-chrome-wasm64-4gb:
     executor: bionic
     environment:
+      EMTEST_LACKS_WEBGPU: "1"
       EMTEST_SKIP_NODE_CANARY: "1"
     steps:
       - run-tests-chrome:

.eslintrc.yml

@@ -22,7 +22,6 @@ ignorePatterns:
   - "src/closure-externs/"
   - "src/embind/"
   - "src/emrun_postjs.js"
-  - "src/worker.js"
   - "src/wasm_worker.js"
   - "src/audio_worklet.js"
   - "src/wasm2js.js"

ChangeLog.md

@@ -18,8 +18,49 @@ to browse the changes between the tags.
 
 See docs/process.md for more on how version tagging works.
 
-3.1.57 (in development)
+3.1.60 (in development)
 -----------------------
+- The `EXPORTED_FUNCTIONS` list can now include JS library symbols even if they
+  have not been otherwise included (e.g. via `DEFAULT_LIBRARY_FUNCS_TO_INCLUDE`).
+  (#21867)
+
+3.1.59 - 04/30/24
+-----------------
+- Fix the location of the dummy `.worker.js` file that is now generated as part
+  of pthread builds so that is generated alongside the main JavaScript file.
+  See #21701. ()
+- `-sASYNCIFY=2` is setting now deprecated, use `-sJSPI` instead.
+- Due to the upstream LLVM change
+  (https://github.com/llvm/llvm-project/pull/80923), multivalue and
+  reference-types features are now enabled by default in Emscripten. This only
+  enables the language features and does not turn on the multivalue ABI.
+
+3.1.58 - 04/23/24
+-----------------
+- The `-sMAIN_MODULE=1` mode no longer exports all the main module symbols on
+  `Module` object.  This saves a huge about of generated JS code due the fact
+  that `-sMAIN_MODULE=1` includes *all* native symbols in your program as well
+  is from the standard library.  The generated JS code for a simple program
+  in this mode is reduced from from 3.3mb to 0.5mb.  The current implementation
+  of this feature requires wasm-ld to be on the program twice which could have a
+  noticeable effect on link times. (#21785)
+- In `-sMODULARIZE` mode, the argument passed into the module constructor is
+  no longer mutated in place.  The expectation is that the module instance will
+  be available via the constructor return value.  Attempting to access methods
+  on the object passed *into* the constructor will now abort. (#21775)
+- Enable use of `::` to escape port option separator (#21710)
+- In multi-threaded builds `--extern-pre-js` and `--extern-post-js` code is
+  now only run on the main thread, and not on each of the workers. (#21750)
+- Fix crash when throwing exceptions in dynamically linked int64 functions (#21759)
+- Multi-threaded builds no depend on a separate `.worker.js` file.  This saves
+  on code size and network requests.  In order to make this change go smoothly,
+  without breaking build systems that expect a `worker.js`, emscripten will
+  generate an empty `.worker.js` to give folks time to transition their
+  deployment scripts.  In `-sSTRICT` mode, this empty file will not be
+  generated. (#21701)
+
+3.1.57 - 04/10/24
+-----------------
 - libcxx, libcxxabi, libunwind, and compiler-rt were updated to LLVM 18.1.2.
   (#21607, #21638, and #21663)
 - musl libc updated from v1.2.4 to v1.2.5. (#21598)
@@ -44,6 +85,15 @@ See docs/process.md for more on how version tagging works.
 - TypeScript definitions for Wasm exports, runtime exports, and embind bindings
   can now be generated with `--emit-tsd`. The option `--embind-emit-tsd` has been
   deprecated, use `--emit-tsd` instead.
+- Added the `ASYNCIFY_PROPAGATE_ADD` setting, to control whether the `ASYNCIFY_ADD`
+  list propagates or not. By default this is enabled; as a result you may see larger
+  ASYNCIFY builds as more of the function tree may be instrumented than you were
+  previously manually specifying in `ASYNCIFY_ADD`. To stop propagation you can
+  specify functions in the `ASYNCIFY_REMOVE` list, or to return to the previous
+  behaviour, disable this setting (set `-sNO_ASYNCIFY_PROPAGATE_ADD`.) (#21672)
+- ports changes:
+  - Fixed transitive link dependencies (#21602)
+  - Enable use of options in ports dependencies (#21629)
 
 3.1.56 - 03/14/24
 -----------------

cmake/Modules/Platform/Emscripten.cmake

@@ -284,7 +284,7 @@ set(CMAKE_CXX_RESPONSE_FILE_LINK_FLAG "@")
 
 # Set a global EMSCRIPTEN variable that can be used in client CMakeLists.txt to
 # detect when building using Emscripten.
-set(EMSCRIPTEN 1 CACHE BOOL "If true, we are targeting Emscripten output.")
+set(EMSCRIPTEN 1 CACHE INTERNAL "If true, we are targeting Emscripten output.")
 
 # Hardwire support for cmake-2.8/Modules/CMakeBackwardsCompatibilityC.cmake
 # without having CMake to try complex things to autodetect these:

emcc.py

@@ -292,12 +292,15 @@ def apply_user_settings():
 
     if key == 'EXPORTED_FUNCTIONS':
       # used for warnings in emscripten.py
-      settings.USER_EXPORTED_FUNCTIONS = settings.EXPORTED_FUNCTIONS.copy()
+      settings.USER_EXPORTS = settings.EXPORTED_FUNCTIONS.copy()
 
     # TODO(sbc): Remove this legacy way.
     if key == 'WASM_OBJECT_FILES':
       settings.LTO = 0 if value else 'full'
 
+    if key == 'JSPI':
+      settings.ASYNCIFY = 2
+
 
 def cxx_to_c_compiler(cxx):
   # Convert C++ compiler name into C compiler name
@@ -369,12 +372,13 @@ def get_clang_flags(user_args):
   if settings.RELOCATABLE and '-fPIC' not in user_args:
     flags.append('-fPIC')
 
-  # We use default visiibilty=default in emscripten even though the upstream
-  # backend defaults visibility=hidden.  This matched the expectations of C/C++
-  # code in the wild which expects undecorated symbols to be exported to other
-  # DSO's by default.
-  if not any(a.startswith('-fvisibility') for a in user_args):
-    flags.append('-fvisibility=default')
+  if settings.RELOCATABLE or settings.LINKABLE or '-fPIC' in user_args:
+    if not any(a.startswith('-fvisibility') for a in user_args):
+      # For relocatable code we default to visibility=default in emscripten even
+      # though the upstream backend defaults visibility=hidden.  This matches the
+      # expectations of C/C++ code in the wild which expects undecorated symbols
+      # to be exported to other DSO's by default.
+      flags.append('-fvisibility=default')
 
   if settings.LTO:
     if not any(a.startswith('-flto') for a in user_args):

emscripten-version.txt

@@ -1 +1 @@
-3.1.57-git
+3.1.60-git

site/source/docs/introducing_emscripten/community.rst

@@ -22,8 +22,9 @@ Feel free to ask questions, share your ideas, or just join the conversation!
 
 Emscripten also has a presence on social media:
 
-- `#emscripten <https://twitter.com/hashtag/emscripten>`_ (Emscripten Hashtag on Twitter)
-- `@kripken <https://twitter.com/kripken>`_ (an Emscripten developer's account on Twitter, mentions Emscripten updates)
+- `@emscripten on Bluesky <https://bsky.app/profile/emscripten.bsky.social>`_
+- `@emscripten on Mastodon <https://fosstodon.org/@emscripten>`_
+- `@emscripten on Twitter <https://twitter.com/emscripten>`_
 
 
 Report a bug

site/source/docs/porting/asyncify.rst

@@ -355,12 +355,16 @@ If you know that some indirect calls matter and others do not, then you
 can provide a manual list of functions to Asyncify:
 
 * ``ASYNCIFY_REMOVE`` is a list of functions that do not unwind the stack.
-  Asyncify will do its normal whole-program analysis, then remove these
-  functions from the list of instrumented functions.
-* ``ASYNCIFY_ADD`` is a list of functions that do unwind the stack, and
-  are added after doing the normal whole-program analysis. This is mostly useful
+  As Asyncify processes the call tree, functions in this list will be removed,
+  and neither they nor their callers will be instrumented (unless their callers
+  need to be instrumented for other reasons.)
+* ``ASYNCIFY_ADD`` is a list of functions that do unwind the stack, and will be
+  processed like the imports. This is mostly useful
   if you use ``ASYNCIFY_IGNORE_INDIRECT`` but want to also mark some additional
-  functions that need to unwind.
+  functions that need to unwind. If the ``ASYNCIFY_PROPAGATE_ADD`` setting is
+  disabled however, then this list will only be added after the whole-program
+  analysis. If ``ASYNCIFY_PROPAGATE_ADD`` is disabled then you must also add
+  their callers, their callers' callers, and so on.
 * ``ASYNCIFY_ONLY`` is a list of the **only** functions that can unwind
   the stack. Asyncify will instrument exactly those and no others.
 

site/source/docs/porting/pthreads.rst

@@ -146,8 +146,6 @@ The Emscripten implementation for the pthreads API should follow the POSIX stand
 
 - Pthreads + memory growth (``ALLOW_MEMORY_GROWTH``) is especially tricky, see `Wasm design issue #1271 <https://github.com/WebAssembly/design/issues/1271>`_. This currently causes JS accessing the Wasm memory to be slow - but this will likely only be noticeable if the JS does large amounts of memory reads and writes (Wasm runs at full speed, so moving work over can fix this). This also requires that your JS be aware that the HEAP* views may need to be updated - JS code embedded with ``--js-library`` etc will automatically be transformed to use the ``GROWABLE_HEAP_*`` helper functions where ``HEAP*`` are used, but external code that uses ``Module.HEAP*`` directly may encounter problems with views being smaller than memory.
 
-Also note that when compiling code that uses pthreads, an additional JavaScript file ``NAME.worker.js`` is generated alongside the output .js file (where ``NAME`` is the basename of the main file being emitted). That file must be deployed with the rest of the generated code files. By default, ``NAME.worker.js`` will be loaded relative to the main HTML page URL. If it is desirable to load the file from a different location e.g. in a CDN environment, then one can define the ``Module.locateFile(filename)`` function in the main HTML ``Module`` object to return the URL of the target location of the ``NAME.worker.js`` entry point. If this function is not defined in ``Module``, then the default location relative to the main HTML file is used.
-
 .. _Allocator_performance:
 
 Allocator performance

site/source/docs/tools_reference/emsdk.rst

@@ -232,44 +232,52 @@ How do I install and activate old Emscripten SDKs and tools?
 
 .. _emsdk-dev-sdk:
 
-How do I track the latest Emscripten development with the SDK?
---------------------------------------------------------------
+How do I track the latest changes with the SDK?
+-----------------------------------------------
 
-It is also possible to use the latest and greatest versions of the tools on the GitHub repositories! This allows you to obtain new features and latest fixes immediately as they are pushed to GitHub, without having to wait for release to be tagged. **No GitHub account or fork of Emscripten is required.**
+To try the latest changes with emsdk you can install and activate a special
+version called ``tot`` (Tip-Of-Tree) which is continuously built and usually
+contains Emscripten and LLVM changes just a few hours after they are committed:
 
-To switch to using the latest upstream git development branch (``main``), run the following:
+::
+
+  ./emsdk install tot
+  ./emsdk activate tot
+
+If you want to build everything yourself from the very latest sources you can
+use ``sdk-main-64bit``:
 
 ::
 
-  # Install git. Skip if the system already has it.
+  # Install git (Skip if the system already has it).
   ./emsdk install git-1.8.3
 
   # Clone+pull the latest emscripten-core/emscripten/main.
-  ./emsdk install sdk-upstream-main-64bit
+  ./emsdk install sdk-main-64bit
 
-  # Set the "upstream-main SDK" as the active version.
-  ./emsdk activate sdk-upstream-main-64bit
+  # Set this as the active version.
+  ./emsdk activate sdk-main-64bit
 
 .. _emsdk-howto-use-own-fork:
 
-How do I use my own Emscripten GitHub fork with the SDK?
---------------------------------------------------------
+How do I use my own Emscripten fork with the SDK?
+-------------------------------------------------
 
-It is also possible to use your own fork of the Emscripten repository via the SDK. This is useful in the case when you want to make your own modifications to the Emscripten toolchain, but still keep using the SDK environment and tools.
+It is also possible to use your own fork of the Emscripten repository via the
+SDK. This is useful in the case when you want to make your own modifications to
+the Emscripten toolchain, but still keep using the SDK environment and tools.
 
-The way this works is that you first install the ``sdk-upstream-main`` SDK as in the :ref:`previous section <emsdk-dev-sdk>`. Then you use familiar git commands to replace this branch with the information from your own fork:
+To to this all you need to do is set the ``EM_CONFIG`` environment variable to
+point to the emsdk emscripten config and then put your own checkout of
+emscripten first in the ``PATH``:
 
 ::
 
-  cd emscripten/main
-
-  # Add a git remote link to your own repository.
-  git remote add myremote https://github.com/mygituseraccount/emscripten.git
-
-  # Obtain the changes in your link.
-  git fetch myremote
+  cd my_emscripten/
 
-  # Switch the emscripten-main tool to use your fork.
-  git checkout -b mymain --track myremote/main
+  # Tell emscripten to use the emsdk config file
+  export EM_CONFIG=/path/to/emsdk/.emscripten
 
-You can switch back and forth between remotes via the ``git checkout`` command as usual.
+  # Now your version of emscripten will use LLVM and binaryen
+  # binaries from the currently active version of emsdk.
+  ./emcc