Web build fails on Emscripten 3.1.58

[akien-mga]

Tested versions

• Reproducible in 4.3.dev (780e1a50408360cf0cf93c0b55b59e9d7b4ad0b1)
• Reproducible in 3.6.beta (after including #91151 so recent Emscripten can be used)

System information

Fedora Linux 39 (KDE Plasma) - Wayland - Vulkan (Forward+) - dedicated AMD Radeon RX 7600M XT (RADV NAVI33) () - AMD Ryzen 7 7840HS w/ Radeon 780M Graphics (16 Threads)

Issue description

Emscripten never fails to disappoint with breaking Godot every other release.

I tested the latest 3.1.58 and our Web editor build is broken (this is with closure compiler, but it fails the same without).

/usr/bin/node /home/akien/Godot/toolchains/emsdk/upstream/emscripten/node_modules/.bin/google-closure-compiler --compilation_level ADVANCED_OPTIMIZATIONS --externs /home/akien/Godot/godot/platform/web/js/engine/engine.externs.js --js /home/akien/Godot/godot/platform/web/js/engine/features.js --js /home/akien/Godot/godot/platform/web/js/engine/preloader.js --js /home/akien/Godot/godot/platform/web/js/engine/config.js --js /home/akien/Godot/godot/platform/web/js/engine/engine.js --js_output_file /home/akien/Godot/godot/bin/godot.web.editor.wasm32.engine.js
Install file: "misc/dist/html/logo.svg" as "bin/.web_zip/logo.svg"
Install file: "misc/dist/html/manifest.json" as "bin/.web_zip/manifest.json"
Install file: "misc/dist/html/offline.html" as "bin/.web_zip/offline.html"
Creating 'bin/godot.web.editor.wasm32.service.worker.js'
Install file: "bin/godot.web.editor.wasm32.service.worker.js" as "bin/.web_zip/service.worker.js"
Building compilation database compile_commands.json
progress_finish(["progress_finish"], [])
/home/akien/Godot/godot/platform/web/js/engine/features.js:75:4: WARNING - [JSC_TYPE_PARSE_ERROR] Bad type annotation. type annotation incompatible with other annotations. See https://github.com/google/closure-compiler/wiki/Annotating-JavaScript-for-the-Closure-Compiler for more information.
  75|    * @typedef {{ threads: boolean }} SupportedFeatures
           ^

/home/akien/Godot/godot/platform/web/js/engine/features.js:76:12: WARNING - [JSC_UNRECOGNIZED_TYPE_ERROR] Bad type annotation. Unknown type SupportedFeatures
  76|    * @param {SupportedFeatures} supportedFeatures
                   ^

0 error(s), 2 warning(s), 73.6% typed
Linking Static Library core/libcore.web.editor.wasm32.a ...
Ranlib Library core/libcore.web.editor.wasm32.a ...
Linking Program bin/godot.web.editor.wasm32.js ...
em++: warning: -pthread + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see https://github.com/WebAssembly/design/issues/1271 [-Wpthreads-mem-growth]
cache:INFO: generating system asset: symbol_lists/4b07af37ace67ce59deb12f4d95eee632ec0a8c4.json... (this will be cached in "/home/akien/Godot/toolchains/emsdk/upstream/emscripten/cache/symbol_lists/4b07af37ace67ce59deb12f4d95eee632ec0a8c4.json" for subsequent builds)
cache:INFO:  - ok
wasm-ld: warning: function signature mismatch: unztell
>>> defined as (i32) -> i64 in core/libcore.web.editor.wasm32.a(file_access_zip.web.editor.wasm32.o)
>>> defined as (i32) -> i32 in core/libcore.web.editor.wasm32.a(unzip.web.editor.wasm32.o)
Creating 'bin/godot.web.editor.wasm32.wrapped.js'
Install file: "bin/godot.web.editor.wasm32.wasm" as "bin/.web_zip/godot.editor.wasm"
Install file: "bin/godot.web.editor.wasm32.worker.js" as "bin/.web_zip/godot.editor.worker.js"
scons: *** [bin/.web_zip/godot.editor.worker.js] bin/godot.web.editor.wasm32.worker.js: No such file or directory
scons: building terminated because of errors.
[Time elapsed: 00:06:08.446]

The missing godot.web.editor.wasm32.worker.js is actually generated in the root folder of the repo, instead of the bin folder.

It works fine with Emscripten 3.1.39, so it regressed somewhere in between.

Steps to reproduce

• Install Emscripten 3.1.58
• Build with scons p=web target=editor

Minimal reproduction project (MRP)

n/a

[akien-mga]

The regression comes from 3.1.58 itself, I built successfully with 3.1.57.

This change sounds pretty relevant:

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)

https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3158---042324

@adamscott @Faless

[Faless]

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)

~While this change isn't the reason for the build failure (see #91202)~ (EDIT: The mentioned change does indeed seem to be the culprit), it's something we need to track, and IMO a very welcome change from upstream since it makes load time faster (one less fetch).

I wonder if/when we could bump to 3.1.58 as the minimum version and do some cleanup in our threaded load/export paths.

[Faless]

Seems like the issue is caused by a bug upstream fixed via https://github.com/emscripten-core/emscripten/pull/21830 (which will be in 3.1.59).

[akien-mga]

Thanks for checking! This is a wontfix then, as there's little point trying to workaround a bug only present in one release.

We can still fix the warnings as you've started doing though.

There's also this one that might be worth a look:

wasm-ld: warning: function signature mismatch: unztell
>>> defined as (i32) -> i64 in core/libcore.web.editor.wasm32.a(file_access_zip.web.editor.wasm32.o)
>>> defined as (i32) -> i32 in core/libcore.web.editor.wasm32.a(unzip.web.editor.wasm32.o)