bump emscripten to 6.0.2#259
Open
pavelsavara wants to merge 424 commits into
Open
Conversation
- Remove redundant externs from `closure-externs.js` that Closure now provides - Include warning suppression for pre-existing Closure issue with `Atomics.waitAsync` - `WARNING - [JSC_INEXISTENT_PROPERTY] Property value never defined on Promise<string>` This is due to https://github.com/google/closure-compiler/blob/master/externs/es6.js#L2691 which does not match the spec https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics/waitAsync#return_value - ~~Update `emdawnwebgpu` to support newer Closure version~~ - emscripten-core#26891
This was removed upstream. See llvm/llvm-project#196566
I'm not sure where this strange name originally came from but its
notable enough to rename it something more consistent/meaningful.
There was one comment saying `v8 uses arguments_` but that doesn't seem
to be true:
```
$ ~/.jsvu/bin/v8 test.js xx
test.js:1: ReferenceError: arguments_ is not defined
console.log(arguments_);
^
ReferenceError: arguments_ is not defined
at test.c:1:13
```
The `thisProgram` global cannot be undefined, since its unconditionally initialized in shell.js with `var thisProgram = './this.program';`
…ore#26915) The test browser.test_sdl_mouse is intermittently failing on macOS Safari. Improve assert() logging to be more fine grained to help troubleshoot the error.
…6916) This is an automatic change generated by tools/maint/rebaseline_tests.py. The following (7) test expectation files were updated by running the tests with `--rebaseline`: ``` codesize/test_codesize_cxx_except.json: 195824 => 195817 [-7 bytes / -0.00%] codesize/test_codesize_cxx_except_wasm.json: 167051 => 167044 [-7 bytes / -0.00%] codesize/test_codesize_cxx_except_wasm_legacy.json: 164931 => 164924 [-7 bytes / -0.00%] codesize/test_codesize_cxx_mangle.json: 262303 => 262296 [-7 bytes / -0.00%] codesize/test_codesize_cxx_noexcept.json: 153979 => 153965 [-14 bytes / -0.01%] codesize/test_codesize_cxx_wasmfs.json: 179806 => 179712 [-94 bytes / -0.05%] codesize/test_codesize_files_wasmfs.json: 63921 => 63811 [-110 bytes / -0.17%] Average change: -0.04% (-0.17% - -0.00%) ``` Co-authored-by: emscripten-bot <emscripten-bot@users.noreply.github.com>
Fix browser.test_sdl_mouse on Safari, by yielding back to the event loop between canvas resize and programmatic mouse event dispatch. This presumably allows the browser to complete relayouting the page, after the canvas element resize (`SDL_SetVideoMode()`), and fixes the mouse event dispatch to occur to proper location.
…26919) Should have been part of emscripten-core#26559. I failed to follow the advice in the comment :)
The set of excluded files here used to perform `f not in excludes` for all matched files, which means we are doing a lot of lookups using the list. For perf (and general coding style) its better to use sets in this case.
…mscripten-core#26909) The `UTF8ToString` function that these all call has this assertion already and with a useful message.
The dylink_all test contains a few extra functions that were previously just not included.
- Add u64 testing - Rename file to match test name - Use @also_with_pthreads decorator
- Remove `IS_64BIT_LOCK_FREE` which is from the fastcomp days - Add `@also_with_pthreads`
llvm/llvm-project#195550 added `-Wattribute-alias`, which warns on type mismatches between an alias and its aliased function. This is currently failing on the waterfall: https://ci.chromium.org/ui/p/emscripten-releases/builders/try/linux/b8681947828444624337/overview This fixes the warnings. I'm not sure if we treat this `dlmalloc.c` as a third party code we should not modify, in which case we can consider adding `-Wno-attribute-alias` in `system_libs.py`. Fixes: emscripten-core#26936
Node workers can start synchronously so there should be no need for this setting in any node tests. I'm not sure how we ended up with so many occurrences here.
…FC (emscripten-core#26937) Note: These should all fall back to using a lock when accessing the 128-bit values. These locks are implemented in `system/lib/compiler-rt/lib/builtins/atomic.c`.
This fails for the same reason as emscripten-core#26934. llvm/llvm-project#195550 added `-Wattribute-alias`, which warns on type mismatches between an alias and its aliased function. I ran `./embuilder build ALL` and confirmed there were no more `-Wattribute-alias` errors.
We don't need/want threads to be `unref` until the worker is up and running. This is important for emscripten-core#26933 since otherwise the node runtime can shut down while a thread is starting up. This change also simplifies the code by limiting the number of places we called `unref` to just one, which also slightly reduces codesize. Also, remove unused `worker.loaded` assignment. Split out from emscripten-core#26933
…6943) JSPI exported functions return a Promise when invoked from JavaScript. However, the generated TypeScript definitions previously typed them as returning synchronous values. Update the TypeScript definition generator to check whether JSPI is enabled and wrap the return types of JSPI exports in a Promise. Also add test coverage for JSPI TypeScript definitions and wildcard matching.
Support for passing a pre-allocated ArrayBuffer via Module['buffer'] was only supported in non-WASM (asm.js) mode, which was completely removed in September 2020 (commit d5ec187) when the fastcomp backend was dropped. Internal usage for passing the `buffer` to pthread workers was also removed in January 2023 (commit a6e8d85).
- Added a `contextmenu` callback that behaves like any other mouse callback, the same way other mouse callbacks are defined - Added `contextmenu` callback tests to `test_html5_core` and `test_html5_unknown_event_target.c`
…re#27202) This should have been part of emscripten-core#24232.
…ripten-core#27203) One explanation for why this argument might have been included back in the day. In older browsers (for example, Firefox versions prior to 6.0, which was released in 2011), omitting the third argument would actually throw a signature mismatch error or cause the browser to fail to register the listener. See https://caniuse.com/mdn-api_eventtarget_addeventlistener_usecapture_parameter_optional
`,` is the default separator for `Array.prototype.join`.
…7136) - Regarding using `throw e` vs `reject(e)`, these are defined to be the same thing inside the `new Promise` executor function.
This adds the epoll syscall surface (headers, libc wrappers, declarations and signatures) with no working implementation, so the boilerplate can land ahead of the host integration. Split out from emscripten-core#27201 so that the larger, more involved host implementation can be reviewed separately. The syscalls are fully wired in but return `-ENOSYS` everywhere for now: * `sys/epoll.h` synced from upstream musl, and removed from the exclude list in `update_musl.py` * musl `epoll.c` wrappers compiled into libc (`epoll_create`/`epoll_create1`/`epoll_ctl`/`epoll_wait`/`epoll_pwait`) * `SYS_epoll_*` -> `__syscall_epoll_*` mappings, declarations in `emscripten/syscalls.h`, and `libsigs.js` signatures * legacy (non-WASMFS) JS `__syscall_epoll_*` return `-ENOSYS` * WASMFS `__syscall_epoll_*` return `-ENOSYS`, matching the existing socket stubs in `syscalls.cpp` * `tools/native_sigs.py` regenerated for the new libc functions The actual readiness/wait-queue host integration (the working epoll) follows in a separate PR.
…ripten-core#27197) I did a quick audit of the current set of default settings. Many of them were not being incorrectly used unconditionally in the code. The following settings are not longer part of the default set: - GL_MAX_TEXTURE_IMAGE_UNITS - SDL_canPlayWithWebAudio - SDL_numSimultaneouslyQueuedBuffers - freePreloadedMediaOnUse - preinitializedWebGLContext - keyboardListeningElement - doNotCaptureKeyboard - extraStackTrace - preloadPlugins - postMainLoop - preMainLoop - forcedAspectRatio - mainScriptUrlOrBlob - onFullScreen - INITIAL_MEMORY - wasmMemory - wasmBinary I have admint the criteria I used to determine which to relegate and which to keep was somewhat arbitrary, but it wend something like this: - Have I seen this used in the wild, i.e. in the bugtracker? - Is the setting used in the default shell.html? - Is the setting heavily represented in the test code? If the answer to all 3 of these was no I selected it for removal.
Modify `_localtime_js` and `_gmtime_js` to return success/failure status, and update `__localtime_r` and `__gmtime_r` to return NULL when they fail. Previously, these JS helper functions returned `void` and would write invalid/NaN values to the `tm` struct when the input time was out of range of the JS `Date` object. This could trigger assertions or result in garbage data. This completes the work started in emscripten-core#26704 (which fixed `mktime` but left `localtime`/`gmtime` unhandled). Added tests to verify: - `localtime` and `gmtime` return NULL on overflow. - `localtime_r` does not modify the `tm` struct on failure. See: emscripten-core#26704
This avoids ever generating an empty version this function, which can show up as dead code in the output. I think the need for separate function here probably came out the complex logic we used to have to re-entering the `run` function. These days with async this function is pretty much straight line.
…27184) Address security findings from zizmor by passing GitHub context variables through the environment instead of expanding them directly in shell scripts.
…6607) Resolves: emscripten-core#24836. Split out from emscripten-core#24733.
…ten-core#27209) The upstream bug is now fixed in nightly and slated for release in 154. Fixes: emscripten-core#27118
Our top level `README.md` was very bare bones. This change adds a few more details. I'd like to followup to adding more to `CONTRIBUTING.md` and maybe trying to unify it with `docs/process.md` and `developers_guide.rst`.
This is the first part of my plan to separate test setup from the compiler setup. Note that we no longer need `fix_js_engine` because we no longer do identity checks on the JS engine anywhere in the test code. i.e. we no longer depend on being able to do `if engine == V8_ENGINE`, and instead we have an `is_engine_v8` helper function. See emscripten-core#27219 and emscripten-core#26453 for the long term reason for doing this, but its also just good hygiene to keep the test setup out of the core compiler.
This means we auto-detect and use the `toResizeableBuffer` method in cases where it is useful. By default this still has no effect because `ALLOW_MEMORY_GROWTH` is not enabled by default. See `TEXTDECODER` for similar ternary setting where we default to 1.
Bump from 5.0.6 to upstream tag 6.0.2, aligned with dotnet/main's structure: - Followed upstream 6.0.2 for all emscripten content (system/, src/, tools/, em*.py, etc.) — 322 of 331 add/add conflicts were identical to the 5.0.6 base and took theirs cleanly. - Re-applied dotnet/main's 9 patches onto 6.0.2 via 3-way merge (base 5.0.6): .gitignore, src/jsifier.mjs, mimalloc alloc-override.c, tools/js_manipulation.py, tools/link.py, tools/maint/create_entry_points.py, tools/system_libs.py merged cleanly; package.json/package-lock.json resolved to keep dotnet's no-devDeps + dnceng-feed policy with 6.0.2's runtime deps (lock regenerated). - Kept dotnet/main's cleanup: dropped test/, site/, docs/, .github/, .circleci/ (re-added by 6.0.2) and emptied .gitmodules. - Verified: 0 unmerged, 0 conflict markers.
…rayBuffers getUnsharedTextDecoderView now copies data when the heap buffer is resizable (GROWABLE_ARRAYBUFFERS), and the GROWABLE_ARRAYBUFFERS default is reverted to 0 (as in the upstream 6.0.3 fix), so TextDecoder.decode() no longer rejects the view.
This was referenced Jul 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Bumps the vendored Emscripten from 5.0.6 → 6.0.2 (upstream tag
6.0.2), merged on top of the currentdotnet/main.Plus merged emscripten-core#27242
How this was merged
The dotnet fork's git history is unrelated to emscripten-core's, so upstream is grafted with
--allow-unrelated-histories(as with prior bumps). With an empty merge base every shared file is anadd/addconflict; becausedotnet/mainalready carries 5.0.6, only 331 files actually differed:5.0.6base → took upstream6.0.2as-is.6.0.2via a 3-way merge (base =5.0.6), all clean:.gitignore,src/jsifier.mjs,system/lib/mimalloc/src/alloc-override.c,tools/js_manipulation.py,tools/link.py,tools/maint/create_entry_points.py,tools/system_libs.py.package.json/package-lock.json→ kept the dotnet policy (nodevDependencies, dnceng feed) with 6.0.2's runtime dependencies; lock regenerated to match.Kept aligned with
dotnet/maintest/,site/,docs/,.github/,.circleci/(re-added by upstream) and emptied.gitmodules.emcc/em++launchers — they are generated at build time viacreate_entry_points.py.emscripten-version.txt=6.0.2-git(the pack step strips-gitintoeng/emscripten-version.txt, as before).Validation
./build.sh --ci --restore --build --pack --arch x64 -c Release: 0 warnings, 0 errors; producedMicrosoft.NETCore.Runtime.Wasm.Emscripten.Transportpackage.libc++and compiles + runs a C++std::stringprogram under Node.src/mono/sample/wasm/browserworks