Possible issue with casting cdecl procs

[mattrberry]

Description

I'll preface this with a couple points:

• This "worked" in v1.6.something with Emscripten at the time
• I'm not sure if this is a Nim bug or an Emscripten bug

When using the default C compiler, the following code compiles and runs in both v1.6 and the current head.

type Data = ref object
type funType = proc(data: pointer) {.cdecl.}
proc fun(data: Data) {.cdecl.} = discard
proc takesFun(fun: funType) = discard
takesFun(cast[funType](fun))

However, compiling with Emscripten (--cc:clang --clang.exe=emcc --clang.linkerexe=emcc) fails at the C compilation step:

/Users/matt/.cache/nim/a_d/@ma.nim.c:135:16: error: incompatible function pointer types passing 'void (tyObject_Datacolo
nObjectType___DNAai3FPsCf5pkobz9abC9cw *)' (aka 'void (struct tyObject_DatacolonObjectType___DNAai3FPsCf5pkobz9abC9cw *)
') to parameter of type 'tyProc__32w2ZypAyMWuajvi2Jt79cg' (aka 'void (*)(void *)') [-Wincompatible-function-pointer-type
s]
        takesFun__a_9(fun__a_7);
                      ^~~~~~~~
/Users/matt/.cache/nim/a_d/@ma.nim.c:72:78: note: passing argument to parameter 'fun__4y3n9aYsUAQZtunW8QkDUBg' here
N_LIB_PRIVATE N_NIMCALL(void, takesFun__a_9)(tyProc__32w2ZypAyMWuajvi2Jt79cg fun__4y3n9aYsUAQZtunW8QkDUBg) {

My understanding of C code is surface-level. Looking at the generated C code, though, it seems that maybe the proc isn't being casted to the expected type?

---

Interestingly, removing the cdecl pragmas results in an error in Nim-land, specifically expression cannot be cast to 'funType'. Is there a preferred way to achieve this?

Nim Version

Nim Compiler Version 1.9.1 [MacOSX: arm64]
Compiled at 2022-12-29
Copyright (c) 2006-2022 by Andreas Rumpf

git hash: 7f6681b
active boot switches: -d:release

Current Output

/Users/matt/.cache/nim/a_d/@ma.nim.c:135:16: error: incompatible function pointer types passing 'void (tyObject_Datacolo
nObjectType___DNAai3FPsCf5pkobz9abC9cw *)' (aka 'void (struct tyObject_DatacolonObjectType___DNAai3FPsCf5pkobz9abC9cw *)
') to parameter of type 'tyProc__32w2ZypAyMWuajvi2Jt79cg' (aka 'void (*)(void *)') [-Wincompatible-function-pointer-type
s]
        takesFun__a_9(fun__a_7);
                      ^~~~~~~~
/Users/matt/.cache/nim/a_d/@ma.nim.c:72:78: note: passing argument to parameter 'fun__4y3n9aYsUAQZtunW8QkDUBg' here
N_LIB_PRIVATE N_NIMCALL(void, takesFun__a_9)(tyProc__32w2ZypAyMWuajvi2Jt79cg fun__4y3n9aYsUAQZtunW8QkDUBg) {

Expected Output

No response

Possible Solution

No response

Additional Information

No response

[mattrberry]

This may be an Emscripten thing, since building Nim at versions 1.4.9 and 1.6.11 still shows the same problem. I'll try looking at a couple Emscripten versions to see if that's the culprit. Regardless, does this seem like a case where Emscripten is being overly restrictive or is Nim's C output somehow ambiguous?

[oakes]

I get a similar error; it began after updating emscripten. I don't know what version it was introduced, but downgrading to emscripten 3.1.0 fixed it.