Issue with opaque struct across modules

[p0nce]

We stumble upon the following problem in dkorpel/libsoundio-d#3 (comment)

module a;

extern(C):

struct A;
void foo(A* a);

module b;

extern(C):

struct A {}
void foo(A* a) {}

When built:

$ ldc2 a.d b.d
a.d(6): Error: Function type does not match previously declared function with the same mangled name: `foo`
a.d(6):        Previous IR type: void (%b.A*)
a.d(6):        New IR type:      void (%a.A*)

But it works in DMD.

This doesn't create problem when module a and b are in different translation units, but typically will be exposed with dub --combined.

What to do?

[kinke]

This is yet another duplicate of #2782, #1020 etc. - hence closing. ;)

What to do?

If possible, extract the struct declaration to a separate module and import it from there. extern(C) doesn't change the fact that there are multiple unrelated struct types, and that there are conflicting foo() functions with different signatures.

[dkorpel]

If possible, extract the struct declaration to a separate module and import it from there. extern(C) doesn't change the fact that there are multiple unrelated struct types, and that there are conflicting foo() functions with different signatures.

Does this mean DMD accepting this is a bug? The spec says that opaque structs can be used to implement the PIMPL idiom, but in LDC they're useless?

[kinke]

It boils down to that you cannot declare the same struct in multiple modules in D. So if the implementation of the struct is in another module, then no, the opaque struct and the impl don't refer to the same type.

[dkorpel]

Does LDC support another way of implementing the PIMPL idiom?

[kinke]

This has nothing to do with LDC per se, this is a general D restriction, it's just that DMD has much less strict codegen checks and according bugs, though one might argue that this extern(C[++]) function signatures check of LDC is overshooting at times and hindering some approaches. For a pimpl thing, I'd probably simply use a void* instead of A*.

[dkorpel]

I'll figure something out, thanks!

[kinke]

To make things clearer:

import a, b;

void main()
{
    A inst;
    foo(&inst);
}

=>

c.d(5): Error: struct `a.A` at a.d(5) conflicts with struct `b.A` at b.d(5)
c.d(5): Error: variable `c.main.inst` no definition of struct `A`

[p0nce]

Does this mean DMD accepting this is a bug?

I think that yes, it's strange to accept it in the first place. the 2 struct have different fully qualified names.