Trying to pass i64 without WASM_BIGINT should warn or assert

[mmarczell-graphisoft]

This code:

#include <cstdint>
#include <emscripten.h>

EM_JS(void, foo, (int64_t i), {
  console.log(i);
})

int main() {
  foo(1);
}

should issue at least a runtime warning if it was not compiled with WASM_BIGINT.

Comments and pointers appreciated for a (hopefully) upcoming PR.

Version of emscripten/emsdk:

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 3.0.0 (3fd52e107187b8a169bb04a02b9f982c8a075205)
clang version 14.0.0 (https://github.com/llvm/llvm-project 4348cd42c385e71b63e5da7e492172cff6a79d7b)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /Volumes/SSD/git/emsdk/upstream/bin

[sbc100]

Good idea. We should probably also add a test to ensure it does work as expected when WASM_BIGINT is enabled.

Looking into this I'm not sure how easy it will be to issue such a warning. BTW, we also don't warn for other unsupported types (e.g. struct types) so this issue is larger than just i64.

[sbc100]

We do have access to the string of the signature, e.g. "(int64_t i)", however we don't have way to know about type names used in the C/C++ code. I'm not sure we can enumberate all the valid types or figure out if a given type lowers to i64. For example, if a user has a typedef called myint64 we don't know what type that is.

We could decide that we only accept a fixed set of names for type in EM_JS macros (for example int, long, int32_t, int8_t, int16_t, etc).. but that might break existing code that uses typedefs.

Alternatively we could look specifically for know-bad types such as long long and int64_t.

I'm not sure either of these options really solves the problem fully though.

[mmarczell-graphisoft]

@sbc100 I assumed, but then it seems, wrongly, that EM_ASM and EM_JS share much more underlying infrastructure, and the assertion from #15830 could be adapted.