Thread overview
fully qualifed IR names causes problems of mismatched definitions
Sep 29
Basile B.
Sep 29
kinke
Sep 29
Basile B.
Sep 30
kinke
Sep 30
Basile B.
September 29

This is a bug report.

The context is that I have bindings that I want to translate with more friendly names and in a less C fashion. There's many to do so I wish to proceed gradually, which leads to an intermediate situation where the C definitions exists in two different modules.

LDC does not like that because it seems that IR names for extern(C) definitions are fully qualified.

Minimal reproduction on linux, file is named test.sh:

echo "module a;
extern(C):
struct S{}
S* create(){return null;} " > a.d

echo "module b;
extern(C):
struct S;
S* create();
void t(){auto s = create();}
" >b.d

echo "module c;
extern(C):
struct S;
S* create();
void main(){auto s = create();}
" > c.d

echo "================DMD================"
dmd a.d b.d c.d
echo "dmd is happy with that"
echo "================GDC================"
gdc a.d b.d c.d
echo "gdc is happy with that"
echo "================LDC================"
ldc2 a.d b.d c.d

which results in:

[xxxx@pc extern_c_irtype_bug]$ bash test.sh
================DMD================
dmd is happy with that
================GDC================
gdc is happy with that
================LDC================
b.d(4): Error: Function type does not match previously declared function with the same mangled name: create
b.d(4):        Previous IR type: %c.S* ()
b.d(4):        New IR type:      %b.S* ()

Maybe that the IR name for extern(C) types should only include the last identifer ?

September 29

On Wednesday, 29 September 2021 at 19:37:28 UTC, Basile B. wrote:

>

This is a bug report.

Yet another duplicate of https://github.com/ldc-developers/ldc/issues/3817.

September 29

On Wednesday, 29 September 2021 at 22:56:17 UTC, kinke wrote:

>

On Wednesday, 29 September 2021 at 19:37:28 UTC, Basile B. wrote:

>

This is a bug report.

Yet another duplicate of https://github.com/ldc-developers/ldc/issues/3817.

too bad for me, firstly detected in 2016 so probably hard to fix.

September 30

On Wednesday, 29 September 2021 at 23:53:44 UTC, Basile B. wrote:

>

too bad for me, firstly detected in 2016 so probably hard to fix.

It's not trivial to fix, but the main reason is that users shouldn't declare structs in different modules and expect them to somehow be magically folded so a single common type (extern(C) has no effect in this regard). Opaque declarations are no exception.

You can work around it for the time being by compiling each module to a separate object file - e.g., by creating a static lib via -lib, or compiling with -c (without -of) and then linking manually.

September 30

On Thursday, 30 September 2021 at 06:04:46 UTC, kinke wrote:

>

On Wednesday, 29 September 2021 at 23:53:44 UTC, Basile B. wrote:

>

too bad for me, firstly detected in 2016 so probably hard to fix.

It's not trivial to fix, but the main reason is that users shouldn't declare structs in different modules and expect them to somehow be magically folded so a single common type (extern(C) has no effect in this regard). Opaque declarations are no exception.

You can work around it for the time being by compiling each module to a separate object file - e.g., by creating a static lib via -lib, or compiling with -c (without -of) and then linking manually.

Yet extern(C) functions dont seem to have this problem, but anyway,
I'll just cheat on LDC the time to finish the translation.

thx again for the explanations.