[wasm2c] Add the very beginning of a wasm2c implementation and test harness

[lexi-nadia]

This change adds an extremely bare-bones wasm2c implementation and test harness.

Most of the code here is imported directly from WABT, particularly the boilerplate code and tests. The only substantive new code is in src/tools/wasm2c/* and scripts/test/wasm2c.py.

I tried to prune this down to be as minimal as possible while still providing a useful checkpoint, but I'm not sure I succeeded. Please feel free to offer suggestions if you see more ways to shrink this down.

[lexi-nadia]

Okay, I uploaded a new draft that incorporates all your feedback. PTAL. Thanks!

[tlively]

LGTM % final comment!

[tlively]

@kripken, any final comments here?

[kripken]

No concerns from me for landing.

(I didn't review the code in detail - let me know if you also want that.)

[tlively]

Looks like the test needs to be updated before this can land.

[lexi-nadia]

Looks like the test needs to be updated before this can land.

It took me a while, but they're finally passing. :)

[sbc100]

This this file was not actually added in this PR it seem to include this here.

BTW, the *.cmake line above seems odd.. does the in-tree build really make files with the .cmake extension?

[lexi-nadia]

I removed this file, and the generation step, in favor of just checking in the "prebuilt" files. I forgot to remove this from .gitignore, though. :( I'll remove it in my next PR (or I can send a one-line PR to remove it, if you'd prefer?).

[sbc100]

I would hope these are not needed, and we don't try to use the same compile flags for building binaryen itself as the generated C source code. i.e. those two sets of flags should probably not be related.

[lexi-nadia]

These flags aren't used for building the generated C source code, but they are used for building the wasm-rt C runtime library. I added this because I couldn't find any other way to get the clang-tidy pass to treat this as C code rather than C++ code (the file extension notwithstanding).

If you have a better idea, I'm happy to change this!

[sbc100]

Fair enough. i'm kind of tempted to say that the wasm-rt C runtime library should also be built with the same flags that the generated code (i.e. not these flags), but whatever works best I guess

[sbc100]

This change seems to be breaking the emscripten-releases roller:

https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket/8674789067983951889/+/u/Build_Binaryen/stdout

FAILED: [code=1] lib/libwasm-rt.dylib 
: && /Volumes/Work/s/w/ir/cache/builder/v8/third_party/llvm-build/Release+Asserts/bin/clang --sysroot=/Volumes/Work/s/w/ir/cache/builder/emscripten-releases/build/binaryen-out/xcode_sdk -no-canonical-prefixes --target=x86_64-apple-darwin -fno-omit-frame-pointer -fPIC -fcolor-diagnostics -DBUILD_LLVM_DWARF -Wall -Werror -Wextra -Wno-unused-parameter -Wno-dangling-pointer -Wno-implicit-int-float-conversion -Wno-unknown-warning-option -Wswitch -Wimplicit-fallthrough -Wctad-maybe-unsupported -Wno-deprecated-declarations -O3 -DNDEBUG -UNDEBUG -arch x86_64 -isysroot /Volumes/Work/s/w/ir/cache/builder/emscripten-releases/build/binaryen-out/xcode_sdk -mmacosx-version-min=11 -dynamiclib -Wl,-headerpad_max_install_names -L/Volumes/Work/s/w/ir/cache/builder/emscripten-releases/build/temp/libcxx-install/lib -stdlib=libc++ -o lib/libwasm-rt.dylib -install_name @rpath/libwasm-rt.dylib src/tools/wasm2c/CMakeFiles/wasm-rt.dir/wasm-rt/wasm-rt-exceptions-impl.c.o src/tools/wasm2c/CMakeFiles/wasm-rt.dir/wasm-rt/wasm-rt-impl.c.o src/tools/wasm2c/CMakeFiles/wasm-rt.dir/wasm-rt/wasm-rt-mem-impl.c.o   && :
clang: error: argument unused during compilation: '-stdlib=libc++' [-Werror,-Wunused-command-line-argument]

[sbc100]

It looks like emscripten-releases is injecting -stdlib=libc++ by setting -DCMAKE_EXE_LINKER_FLAGS which unfortunately is global to all programs, but when this new library is built using clang (not clang++) that argument is ignored.

I wonder, could libwasm-rt always be a static library? That would avoid this issue?