We no longer need to test c++17 since that is the default used, but we
should ensure we maintain compatibility with c++11.

The C++ functions that take `std::nothrow_t` all take a reference.
Without this change I'm seeing function signature mismatches because the
final argument is not pointer-width.  I'm guessing this simply went
unnoticed because most platforms don't do signature checking in the
linker and this just happens to work.

e.g.  `_ZnwjRKSt9nothrow_t` which demangles to `operator new(unsigned
int, std::nothrow_t const&)`

See upstream bug at microsoft/mimalloc#840.

Bumps [github/codeql-action](https://github.com/github/codeql-action) from 2.22.5 to 3.23.1.
- [Release notes](https://github.com/github/codeql-action/releases)
- [Changelog](https://github.com/github/codeql-action/blob/main/CHANGELOG.md)
- [Commits](github/codeql-action@74483a3...0b21cf2)

---
updated-dependencies:
- dependency-name: github/codeql-action
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

…ipten-core#21103)

This allows us to use `compiler_for` to determine whether to run
`EMCC` or `EMXX` appropriately.

…pten-core#21131)

…re#21119)

For some reason this actually saves on code size too.

Fixes test browser.test_webgpu_basic_rendering_closure by fixing
wgpuShaderModuleGetCompilationInfo (compilationInfo.messages.length).

Fixes: emscripten-core#20415

There was only one single place (out of hundreds) where this was set
and one single place in `doStat` where it was read.

I removed the `doStat` workaround by updating `mayLookup` instead.

…ripten-core#21147)

Fixes emscripten-core#21084

…ore#21138)

Also remove the special logging and just use assert which fails
fast and gives a backtrace.

Split out from emscripten-core#21151.

The only semantic change here is the fix the type of second argument to
to the array member getter function (previously it was using
`m.type` which is the array type itself, but that second argument to the
setter function is actually the inner type `m.type.inner`.

This enables the type of this argument to be checked correctly, which in
turn required a minor fix to the test case.  This only effects
`IDL_CHECKS=all` builds.

…. NFC (emscripten-core#21164)

See emscripten-core#21163

This was used to demangle C++ symbols JS stacktraces.  However for
a long time now native symbols in JS backtraces are already demanged
because names in the name section are in demangled form.  So this
function has not done anything for a very long time.

As a followup I think we can probably completely remove the
`DEMANGLE_SUPPORT` settings.

…1117)

`-pthread` + `-sEXPORT_ES6` emits a top-level await expression
in the main worker file after commit 49ab23a. Ensure the Acorn
optimizer is aware of this.

Co-authored-by: Jerry.Zhuang <[email protected]>

…re#21170)

I noticed that `proc_exit` was depending on `SYSCALLS` even though
it wasn't actually using `SYSCALLS`.

…1168)

Previously, AOT JS glue code for method pointers used the address of the
method pointer as a unique ID to match JS glue with the binding. However,
sometimes static initializers malloc different sizes when running
the AOT generation code versus when the code is run normally. This caused
the method pointer address to be different and the binding didn't match up.

Instead of using the function pointer or the method pointer address we now
use a generated signature for the invoker to match up the glue code. This
works for both types of pointers and also has the advantage that many
of the glue code functions are nearly identical and can be reusued (closure
arguments make them behave differently).

Fixes emscripten-core#20994

This chance also includes a couple of minor fixes to asan + memory64
that helped me to confirm that it really doesn't work yet.

See emscripten-core#21177

The poppler test also seesm to work fine under wasm64, just not the >4Gb
mode.

Also add test_TextDecoder to the list of test.

…emscripten-core#21184)

See emscripten-core#21191

…#21181)

This test was originally added with these unused args. Perhaps while
it was being developed in was parameterized, but is not anymore.

…core#21197)

This only seems to show up in `browser.test_sdl_ogl_regal`.

…scripten-core#21189)

These 6 extensions don't add any entry points, so shouldn't require any
Emscripten support (aside from having any enums present in gl2ext.h,
which they do):

- EXT_conservative_depth
- NV_shader_noperspective_interpolation
- EXT_depth_clamp
- WEBGL_blend_func_extended
- WEBGL_compressed_texture_etc
- WEBGL_compressed_texture_etc1

Finally:

- WEBGL_compressed_texture_astc does add an entry point
getSupportedProfiles() in WebGL. This is a WEBGL_ extension, so it is
still safe to allow-list without implementing a C version of that
function. There is no corresponding GLES entry point for this; instead,
profile support is indicated by the presence of
KHR_texture_compression_astc_{ldr,hdr}. Emscripten should emulate those
extensions by checking getSupportedProfiles(), but I haven't implemented
this. Applications can still use the WEBGL_ version directly.

  WEBGL_compressed_texture_astc guarantees support for the LDR profile
  (since HDR is a superset of LDR, and there are only two profiles), so
  applications that only need LDR don't need to call this function. It
  can also be easily called using EM_ASM in applications that do use the
  HDR profile.

Fixes emscripten-core#21183

This allows `unsafe_optimizations.js` to cleanup some thing that
closure compiler was able to remove usages of.

Split out from emscripten-core#21195

This test recently flaked on window too.

…#21195)

Setting `IMPORTED_MEMORY` can have other implications and don't want t
by default just because we chose WASM2JS.

The there is a very minor code size regression here that only effects
WASM2JS, but when combined with emscripten-core#21196 the overall effect is still a
win.

See emscripten-core#21071

…1216)

Fixes: emscripten-core#21215

…n-core#21207)

This means that filenames will sort correctly under normal sorting rules.

See emscripten-core#21177

…re#21204)

The `emscripten_` naming convention is something we use for native
function and this symbol is not visible to native code.

We were previously only applying this flag to tests that use
`self.build` (i.e. most test).  Now we apply it to and even larger set.

The code size changes here only occur in debug builds where we enumerate
all known JS symbols, and there are come JS symbols are the C++ only.

…re#21220)

This is an overall size win too after compression.

…n-core#21206)

…ipten-core#21224)

emscripten-core#21228)

The first problem here was that
emscripten_webgl_make_context_current_calling_thread had the
wrong signature.

The second issue was use of `>> 2` on a pointer in
`emscripten_webgl_do_create_context` which doesn't work under wasm64
or CAN_ADDRESS_2GB.

…mscripten-core#21236)

This is very useful for doing things like `./embuild build libGL*` to
`./embuilder clean libc*`.

This only have one user, and we have a cleaner mechanism for doing
this these days in terms of the decorator.

…ripten-core#21225)

- The function simpleReadValueFromPointer was always reading pointers as
i32 numbers which was incorrect on wasm64.
- Decoding of std::wstring was using a right shift to read pointers. Right
  shift was truncating numbers larger than i32 and causing misreads.
- Added tests to execute readValueFromPointer on all the binding types
  to ensure these don't break on wasm64.

…re#21239)

This is in preparation for enabling these functions under wasm64.

…1237)

…e#21102)

This helps create better TypeScript definitions for what
is actually returned.

…re#21231)

Co-authored-by: Kai Ninomiya <[email protected]>

This test was broken by emscripten-core#21103 but when unnoticed because we run our
browser tests with swiftshader enabled, which skips this test.

…ore#21245)

This is in preparation for a change to avoid using json parsing for
settings by default.

It also adds more context to the errors since when the ValueError
is caught higher up we print nice error messages.

This bug only showed up under wasm64 when the address of the fetch
object was between 2Gb and 4Gb.  This causes the JS ">> 2" operation to
generate a negative number becuase the high bit is set:

```
$ node
> a = 2**31 + 10
2147483658
> a >> 2
-536870910
>
```

In `browser64_4gb` mode this bug resulted in a read from the first 4gb
of memory somewhere, which results a in 0 whereas read from a negative
address yields `undefined`.

This should have been part of emscripten-core#21096.  These failures don't show up in
CI because they are disabled under swiftshader.

…e#21249)

This change got reverted in emscripten-core#19006 so this time we make the
preprocessing optional.

This is useful as it allows things like `{{{ POINTER_SIZE }}}`
and `{{{ makeGetValue(..) }}}` to be used in pre/post JS files, just
like they can be in JS library files.

This change allows threadprofiler.js to be fixed such that it works
under wasm64.

Fixes: emscripten-core#21226

This is partially a workround for emscripten-core#21250

These are outdated and the docker images mentioned here haven't
been updated in 4 years.

Rather than embedding `reftest.js` directly in the html, simply include
it via script src attribute.

This function only ever gets called with no arguments.

I also confirmed that when we use a memory init file, that file always
exists.

Modernize this test a little by using fetch API and JS spread operator.

…pten-core#8167)

…mscripten-core#21269)

…#21261)

…-core#21270)

These operators are available everywhere that we can run mutli-threaded
code.

…e#21266)

- Use fetch() over XHR.
- No need for tryParseAsDataURI. This code is already in a `not
  settings.SINGLE_FILE` block which means URL for the wasm binary
  will never be data URI.  See `get_subresource_location`.

* WebGPU: added GetCurrentTexture method to swapchain.

* WebGPU: fix for GetCurrentTexture signature.

…resolved. NFC (emscripten-core#21164)" (emscripten-core#21282)

This reverts commit 0eb6567.

The upstream has been fixed: https://bugzilla.mozilla.org/show_bug.cgi?id=1876355#c3

…21280)

Followup to emscripten-core#21227

…mscripten-core#21281)

In particular this changes the return type of
`emscripten_webgl_create_context` such that negative values can no
longer be returned.

This allows pointers (specifically 32-bit pointers over 2gb) to be
returned which is needed for pthread builds.

The only valid failure return code for `emscripten_webgl_create_context`
is now 0/NULL.  As it happens this function never fails with anything
except 0 so this should not be an impactful change.

Split out from emscripten-core#21268

Fixes: emscripten-core#21278

* It is implicitly enabled for .mjs output.
* MODULARIZE is implicitly enabled when EXPORT_ES6 is set.

This stop in the chain is only need if the offset converter is needed.