Remove unneeded buffer global

[sbc100]

If this is needed it can always be found via HEAPXX, or wasmMemory.

Also introduce a new debug helper called missingGlobal which allows
us to remove builtin global symbols while notifying any folks that
are depending on them.

[kripken]

Looks like it might add a few bytes, but the simplification seems worth it.

(Removing the parameter should have decreased code size, but maybe closure was doing that all along anyhow?)

[sbc100]

Looks like it might add a few bytes, but the simplification seems worth it.

(Removing the parameter should have decreased code size, but maybe closure was doing that all along anyhow?)

Yes, it only adds bytes in non-optimizing builds, but I also think it make non-optimized builds more readable.

For optimized builds its a wash (I assume because of closure).

[sbc100]

I'm going to add a ChangeLog entry for this I think

[juj]

This regressed Unity's end user at https://forum.unity.com/threads/arrays-shared-between-c-and-jslib-in-webgl-buffer-undefined-in-2023-3-0a6.1495094/ .

In Emscripten documentation, I see there is one location that still looks like is referencing buffer:

site\source\docs\optimizing\Module-Splitting.rst:

Here’s code implementing the base64 solution::

  var profile_data = new Uint8Array(buffer, ptr, len);

Also, we still have the following

site\source\docs\api_reference\module.rst:

.. js:attribute:: Module.buffer

  Allows you to provide your own ``ArrayBuffer`` or ``SharedArrayBuffer`` to use as the memory.

  .. note:: This is only supported if ``-sWASM=0``. See ``Module.wasmMemory`` for WebAssembly support.

site\source\docs\compiling\Deploying-Pages.rst:

See the fields ``Module['buffer']`` and ``Module['wasmMemory']`` for more information.

is the intent to get rid of Module['buffer'] as well? (not that the JS scope and Module objects would generally be symmetric, but just to be sure)

In terms of code size, this PR is a pessimization. I think the code size comparison above was not apples-to-apples, due to also removing the function parameter in the PR.

In small test programs, a dedicated let buffer = wasmMemory.buffer; variable assignment would dominate (minifies down to ,b=w.buffer), but in larger programs, the number of references to wasmMemory.buffer or HEAP8.buffer will all weigh +2 bytes compared to before this change, so will overtake the constant overhead at some point.

[sbc100]

I don't think this this change effected Module['buffer']. I don't think that was available before this change either. From the docs it looks like maybe it was pre-wasm thing?

Looking at the codebase it doesn't look like references to wasmMemory.buffer or HEAP8.buffer should be very common. Do you know why the user in question was depending on it? i.e. what were they looking to do with buffer? I assume this reference was in libary-js code?

[sbc100]

The readable Module['buffer'] was removed in #8277.

Module['buffer'] and Module['wasmMemory'] can still be used as part of the incoming module API which is what those docs are referring too I believe.