digitalmars.D.ldc - fully qualifed IR names causes problems of mismatched definitions
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_:
```bash
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:
```console
[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 ?
Sep 29 2021
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.
Sep 29 2021
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:too bad for me, firstly detected in 2016 so probably hard to fix.This is a bug report.Yet another duplicate of https://github.com/ldc-developers/ldc/issues/3817.
Sep 29 2021
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.
Sep 29 2021
Basile B. <b2.temp gmx.com> 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: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.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.
Sep 30 2021