1.37.36: Function pointer cast emulation (#1468)

This adds a pass that implements "function pointer cast emulation" - allows indirect calls to go through even if the number of arguments or their types is incorrect. That is undefined behavior in C/C++ but in practice somehow works in native archs. It is even relied upon in e.g. Python.

Emscripten already has such emulation for asm.js, which also worked for asm2wasm. This implements something like it in binaryen which also allows the wasm backend to use it. As a result, Python should now be portable using the wasm backend.

The mechanism used for the emulation is to make all indirect calls use a fixed number of arguments, all of type i64, and a return type of also i64. Thunks are then placed in the table which translate the arguments properly for the target, basically by reinterpreting to i64 and back. As a result, receiving an i64 when an i32 is sent will have the upper bits all zero, and the reverse would truncate the upper bits, etc. (Note that this is different than emscripten's existing emulation, which converts (as signed) to a double. That makes sense for JS where double's can contain all numeric values, but in wasm we have i64s. Also, bitwise conversion may be more like what native archs do anyhow. It is enough for Python.)

Also adds validation for a function's type matching the function's actual params and result (surprised we didn't have that before, but we didn't, and there was even a place in the test suite where that was wrong).

Also simplifies the build script by moving two cpp files into the wasm/ subdir, so they can be built once and shared between the various tools.

version_45: Function pointer cast emulation (#1468)

This adds a pass that implements "function pointer cast emulation" - allows indirect calls to go through even if the number of arguments or their types is incorrect. That is undefined behavior in C/C++ but in practice somehow works in native archs. It is even relied upon in e.g. Python.

Emscripten already has such emulation for asm.js, which also worked for asm2wasm. This implements something like it in binaryen which also allows the wasm backend to use it. As a result, Python should now be portable using the wasm backend.

The mechanism used for the emulation is to make all indirect calls use a fixed number of arguments, all of type i64, and a return type of also i64. Thunks are then placed in the table which translate the arguments properly for the target, basically by reinterpreting to i64 and back. As a result, receiving an i64 when an i32 is sent will have the upper bits all zero, and the reverse would truncate the upper bits, etc. (Note that this is different than emscripten's existing emulation, which converts (as signed) to a double. That makes sense for JS where double's can contain all numeric values, but in wasm we have i64s. Also, bitwise conversion may be more like what native archs do anyhow. It is enough for Python.)

Also adds validation for a function's type matching the function's actual params and result (surprised we didn't have that before, but we didn't, and there was even a place in the test suite where that was wrong).

Also simplifies the build script by moving two cpp files into the wasm/ subdir, so they can be built once and shared between the various tools.

1.37.35: Say "wat" instead of "wast". (#1430)

http://webassembly.org/docs/text-format/ says:

> The recommended file extension for WebAssembly code in textual format
> is .wat.

> Note: The .wast format understood by some of the listed tools is a
> superset of the .wat format that is intended for writing test scripts.

1.37.34: determinism fix: hash results may differ between runs (#1431)

Hash results may differ between runs, as they can depend on pointers. In remove-duplicate-functions, that shouldn't matter, except that we only considered the first item in each hash group vs the others (to avoid O(N^2)), which is fine except for hash collisions (collisions mean 2 groups are merged into one, and considering just the first item vs the rest we miss out on the other duplicates in that single group). And hash collisions do occur (rarely) in practice. Instead, consider all comparisons in each hash group, which should be fine unless we have large amounts of hash collisions.

version_44: determinism fix: hash results may differ between runs (#1431)

Hash results may differ between runs, as they can depend on pointers. In remove-duplicate-functions, that shouldn't matter, except that we only considered the first item in each hash group vs the others (to avoid O(N^2)), which is fine except for hash collisions (collisions mean 2 groups are merged into one, and considering just the first item vs the rest we miss out on the other duplicates in that single group). And hash collisions do occur (rarely) in practice. Instead, consider all comparisons in each hash group, which should be fine unless we have large amounts of hash collisions.

1.37.33

Fix hard-wired buffer limit in the JS API (#1394)

1.37.32: Simplify ThreadPool::isRunning (#1391)

* simplify ThreadPool::isRunning: it doesn't need to be static and to go through the global unique_ptr

* it's undefined behavior to access the threadpool from a shutting down thread, as the parent is being destroyed

1.37.31: Simplify ThreadPool::isRunning (#1391)

* simplify ThreadPool::isRunning: it doesn't need to be static and to go through the global unique_ptr

* it's undefined behavior to access the threadpool from a shutting down thread, as the parent is being destroyed

1.37.30: Simplify ThreadPool::isRunning (#1391)

* simplify ThreadPool::isRunning: it doesn't need to be static and to go through the global unique_ptr

* it's undefined behavior to access the threadpool from a shutting down thread, as the parent is being destroyed

1.37.29

Show the binary bytes we can remove without each export, in --func-me…