Bug 23723 – Attributes incorrectly inferred given the same source but compiled individually

This will compile with dmd-2.101.2, but will produce a linking error when using dmd-2.102.0 or dmd-2.102.1 After upgrading DMD my project it will not build, reducing this was a head scratcher. this is my first time reporting on the tracker here, so hopefully I did a good job, if not, please tell what to do better next time. I'm not sure what is going on, but I think this has something to do with attributes being inferred incorrectly, but I may be off the mark, what's also odd is that if you pass both files at once this bug will not be reproduced. using `nm` I can see two different signatures void std.typecons.SafeRefCounted!(test2.MyStruct, 1).SafeRefCounted.__dtor() pure nothrow @nogc void std.typecons.SafeRefCounted!(test2.MyStruct, 1).SafeRefCounted.__dtor() How to reproduce bug: build using: dmd -c test.d && dmd -c test2.d && dmd test.o test2.o test.d ``` void main(){ import test2; MyStruct.RcPtr gl_indcies = MyStruct.RcPtr(MyStruct()); } ``` test2.d ``` module test2; struct MyStruct{ import std.typecons : SafeRefCounted, Unique; alias Ptr = Unique!(MyStruct); alias RcPtr = SafeRefCounted!(MyStruct); ~this(){} } ``` this is the linking error produced ``` /bin/ld: test.o: in function `_Dmain': test.d:(.text._Dmain[_Dmain]+0x2f): undefined reference to `_D3std8typecons__T14SafeRefCountedTS5test28MyStructVEQBzQBy24RefCountedAutoInitializei1ZQCs6__dtorMFZv' collect2: error: ld returned 1 exit status ```a

As a workaround, templating MyStruct will yield a successful compilation.

(In reply to 212fahrenheit from comment #0) > This will compile with dmd-2.101.2, but will produce a linking error when > using dmd-2.102.0 or dmd-2.102.1 > > After upgrading DMD my project it will not build, reducing this was a head > scratcher. this is my first time reporting on the tracker here, so hopefully > I did a good job, if not, please tell what to do better next time. > > I'm not sure what is going on, but I think this has something to do with > attributes being inferred incorrectly, but I may be off the mark, what's > also odd is that if you pass both files at once this bug will not be > reproduced. > > using `nm` I can see two different signatures > > void std.typecons.SafeRefCounted!(test2.MyStruct, 1).SafeRefCounted.__dtor() > pure nothrow @nogc void std.typecons.SafeRefCounted!(test2.MyStruct, > 1).SafeRefCounted.__dtor() > > > How to reproduce bug: > > build using: dmd -c test.d && dmd -c test2.d && dmd test.o test2.o > > test.d > ``` > void main(){ > import test2; > MyStruct.RcPtr gl_indcies = MyStruct.RcPtr(MyStruct()); > } > ``` > > test2.d > ``` > module test2; > struct MyStruct{ > import std.typecons : SafeRefCounted, Unique; > alias Ptr = Unique!(MyStruct); > alias RcPtr = SafeRefCounted!(MyStruct); > ~this(){} > } > ``` > > this is the linking error produced > ``` > /bin/ld: test.o: in function `_Dmain': > test.d:(.text._Dmain[_Dmain]+0x2f): undefined reference to > `_D3std8typecons__T14SafeRefCountedTS5test28MyStructVEQBzQBy24RefCountedAutoI > nitializei1ZQCs6__dtorMFZv' > collect2: error: ld returned 1 exit status > ```a Reduce to not include phobos: //test.d void main() { import test2; MyStruct.Ptr a; } // test2.d struct MyStruct { alias Ptr = Unique!(MyStruct); ~this(){} } struct Unique(T) { /// Transfer ownership from a `Unique` of a type that is convertible to our type. void opAssign(U)(Unique!U u) if (is(u.RefT : RefT)) { } ~this() { if (_p !is null) { destroy(*_p); //_p.__dtor(); } } T* _p; }

(In reply to RazvanN from comment #1) > As a workaround, templating MyStruct will yield a successful compilation. Thank you, that is very helpful, I just applied that & it works well, so at least I will not have to use an out of date compiler until the bug is resolved.

Looks like this is a library regression, not compiler.

Introducing commit d5c10671317ca1f3de61acd8be760d1b77aed3a2 https://github.com/dlang/phobos/pull/8651

It's a compiler bug, originally reported in 2017, several years before the linked Phobos PR was merged. *** This issue has been marked as a duplicate of issue 17541 ***