[clang] [clang][WebAssembly] Handle casted function pointers with different number of arguments (PR #153168)

[Jorge Zapata via cfe-commits]

turran wrote:

Hello @dschuff, thanks for getting back to this issue

> I can see that trying to fix up callsites in Binaryen transparently is probably infeasble, although I still have basically the same objections the proposed approach that were expressed by @efriedma-quic and myself above.
> 
> I'm doing some prototyping experiments with different approaches, and the way I'm validating them is to try locally modifying glib to support Emscripten and get the tests to pass (at least, the ones that don't depend on unsupported posix features). I hope to have more to say different approaches shortly. But the first thing I tried was to apply this patch to clang, and then try to see whether it is sufficient to make glib work. The first approach was to turn a coding agent loose and let it try to make the tests pass. This doesn't result in upstreamable changes, but it does identify places in the code that must be modified.
> 

As I mentioned before, keep in mind that the GLib maintainers have a strict stance on the potential changes to address this situation. Check https://gitlab.gnome.org/GNOME/glib/-/blob/main/docs/toolchain-requirements.md?ref_type=heads#function-pointer-conversions. They state that the toolchain must handle function pointer mismatch; any other attempt will be discarded, as it already happens to us in a MR we opened.

> And it appears that this patch is not sufficient to make glib transparently work. Mostly because there are plenty of casts in glib that are actually runtime casts and not compile-time casts. For example in [gslist.c](https://github.com/dschuff/glib/commit/f9fd9acd4213e67eebd71dd74900cfb360ea2ddf#diff-48030e2aa9b604d2a85bf174ef9ea31ef32d5341128d6317544d88a2551f82bbL1032-R1039) the list iteration functions are calling callbacks that are either 2-argument `GCompareFunc` or 3-argument `GCompareDataFunc`, but it can't tell statically which one it is; the cast is a runtime cast. LIkewise [g_queue_foreach](https://github.com/dschuff/glib/commit/f9fd9acd4213e67eebd71dd74900cfb360ea2ddf#diff-3196da21408e1f1c02f7923adfdd6680077d395feeeceff925665e711f4c7cb9L84-L87) does runtime casts on callbacks of type `GFunc` (2 arguments), but can't tell statically when it gets a function that only takes one argument (like `free_func` in the example).
> 
> It doesn't seem like a flag that has these drawbacks and only implements part of a solution is worth it.

Correct. The current approach only handles static, compile-time casts, not runtime casts. The same as the former WebAssemblyFixFunctionBitcasts. Even if only static handling is done, it fixes the main problem with GType inheritance, enabling a fully functional GStreamer port to WebAssembly (gst.wasm).
If this has a go, the runtime check implementation is also doable.

Do you want me to include that as part of this PR?

https://github.com/llvm/llvm-project/pull/153168