I notice there is a widely coding pattern in build/static_src/CompiledXType.c. It will cause a trap during execution(Step 18.) when using as a wasm32-wasi target.

Take CompiledFunctionType.c as an example.

• Define Nuitka_Function_get_name as static PyObject *Nuitka_Function_get_name(struct Nuitka_FunctionObject *function). With one argument.
• When refer it in static PyGetSetDef Nuitka_Function_getset[], cast it to getter(from Include/descrobject.h). It means cast PyObject*(struct Nuitka_FunctionObject*) -> PyObject *(PyObject *, void *).
• Therefore, callers will execute Nuitka_Function_get_name in a form likes get(obj, closure)(getset_get() in Objects/descrobject.c).

From caller side, callee is a function with two arguments. On the other side, callee is a function with one argument. It works well in C. But it confuses wasm.

A call with function pointers will be transferred into call_indirect in Wasm, and pack the callee type together. During execution, there is a type check between expected function type(like PyObject*(void*,void*)) and actually function type(PyObject*(void*)) (all pointers are same types). Eventually, the checker will hit a trap because of different amount of arguments.

P.S.

I am thinking about using a different function signature for wasm32-wasi target like:

#if __wasi__
static PyObject *Nuitka_Function_get_name(struct Nuitka_FunctionObject *function, void *data) {
#else
static PyObject *Nuitka_Function_get_name(struct Nuitka_FunctionObject *function) {
#endif