[Issue 22674] ImportC: compatible types declared in different translation units are not treated equivalent in D.

Jan 14, 2022

dave287091@gmail.com

Jan 22, 2022

May 16, 2022

May 16, 2022

May 16, 2022

May 16, 2022

May 16, 2022

Jul 30, 2022

Sep 21, 2022

Sep 21, 2022

Sep 22, 2022

https://issues.dlang.org/show_bug.cgi?id=22674 dave287091@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |ImportC --

January 22, 2022

[Issue 22674] ImportC: compatible types declared in different translation units are not treated equivalent in D.

Posted by Walter Bright

Permalink

Walter Bright

Permalink

https://issues.dlang.org/show_bug.cgi?id=22674

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|---                         |WONTFIX

--- Comment #1 from Walter Bright <bugzilla@digitalmars.com> ---
I looked into making an adjustment to the compiler, which would be regarding types in C imports with the same name be the same type. Unfortunately, the D compiler is designed around types are the same if they have the same address. Changing this would be very difficult, and would impair speed even if it never actually happens.

But there is a solution. Accessing things from D can be qualified, so:

  import maker;
  import freer;

  void do_foo(){
    auto f = cast(freer.FooRef)make_foo();
    free_foo(f);
  }

Doing this in ImportC is slightly trickier, as C doesn't have name qualification:

  __import maker;
  __import freer : FooRef;

  void do_foo(){
    FooRef f = (FooRef)make_foo();
    free_foo(f);
  }

Once could go further by creating a D file that merges the duplicate declarations:

  import maker;
  import freer;

  alias FooRef = maker.FooRef;
  extern (C) void free_foo(FooRef foo);

and then importing that module. This works because the declaration of free_foo() will link without problems with the definition of free_foo() where ever it may be, as C name mangling does not mangle in the types. This merged D file may be imported either by D code or ImportC code.

Hence, I'm going to mark this as WONTFIX because it is too disruptive, and accommodations are available that aren't too bad.

--

https://issues.dlang.org/show_bug.cgi?id=22674 dave287091@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX |--- --- Comment #2 from dave287091@gmail.com --- If the goal is to have seamless C importing where you can just import c headers and the compiler even runs the preprocessor for you, I can’t see how this is an acceptable outcome. Even basic thing’s like stdio’s FILE* fall victim to this bug. --

https://issues.dlang.org/show_bug.cgi?id=22674 Adam D. Ruppe <destructionator@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |destructionator@gmail.com --

https://issues.dlang.org/show_bug.cgi?id=22674 --- Comment #3 from Adam D. Ruppe <destructionator@gmail.com> --- i wanna subscribe to this too as i also wrote about it: http://dpldocs.info/this-week-in-d/Blog.Posted_2022_05_16.html#importc-and-module-namespaces Working on isolated unittests and one day toys is one thing. Working in a real world project that has more than one piece is another. My proposal there is to bring the importC declarations into a global implementation-defined module, then the other names work like `mixin templates` or `aliases` for disambiguation purposes. --

https://issues.dlang.org/show_bug.cgi?id=22674 mhh <maxhaton@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxhaton@gmail.com Severity|normal |major --- Comment #4 from mhh <maxhaton@gmail.com> --- This bug is an important canary for ImportC be anything other than toy. Note that resolving this issue may not be a fix for this particular bug but rather completely reframing how C code works. --

https://issues.dlang.org/show_bug.cgi?id=22674 Susan <su+dlangissues@angel-island.zone> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |su+dlangissues@angel-island | |.zone --

https://issues.dlang.org/show_bug.cgi?id=22674 --- Comment #5 from dave287091@gmail.com --- C23 has actually changed the rules and even allows compatible redeclaration of types *within* a translation unit to be treated as the same. --

https://issues.dlang.org/show_bug.cgi?id=22674 Dlang Bot <dlang-bot@dlang.rocks> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull --- Comment #6 from Dlang Bot <dlang-bot@dlang.rocks> --- @WalterBright updated dlang/dmd pull request #14461 "fix Issue 22674 - ImportC: compatible types declared in different tra…" fixing this issue: - fix Issue 22674 - ImportC: compatible types declared in different translation units are not treated equivalent in D https://github.com/dlang/dmd/pull/14461 --

https://issues.dlang.org/show_bug.cgi?id=22674 Dlang Bot <dlang-bot@dlang.rocks> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dlang Bot <dlang-bot@dlang.rocks> --- dlang/dmd pull request #14461 "fix Issue 22674 - ImportC: compatible types declared in different tra…" was merged into master: - b9c117f38171eca71f092863356cf851532392bc by Walter Bright: fix Issue 22674 - ImportC: compatible types declared in different translation units are not treated equivalent in D https://github.com/dlang/dmd/pull/14461 --

Forums