www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bug in TypeInfo generation?

reply Benjamin Thaut <code benjamin-thaut.de> writes:
Lets say I have a library and it contains the following module:

module a;

struct SomeStruct
{
   string name;
}

struct SomeOtherStruct(T)
{
   ~this()
   {
     typeid(T).initializer;
   }
}

struct ThirdStruct
{
   SomeOtherStruct!SomeStruct m;
}

And now I have a second module:

module b;

import a;

int main()
{
   return 0;
}

I would expect that I can compile module .b into an executable like this:

dmd -m64 b.d

As I'm not using anything from module a I would expect that this 
compiles and links just fine. It does not, it gives linker errors:

b.obj : error LNK2001: unresolved external symbol 
"_D1a10SomeStruct9__xtoHashFNbNeKxSQBgQBhZm".
b.obj : error LNK2001: unresolved external symbol 
"_D1a10SomeStruct11__xopEqualsFKxSQBfQBgKxQjZb".

Debugging dmd a bit shows that the typeid expression in the destructor 
of SomeOtherStruct causes the type info of SomeStruct to be created and 
then in the gen object phase the full type info for SomeStruct is 
written into the object file. This is a bug in my eyes though. The 
compiler should be able to figure out that the destructor of 
SomeOtherStruct must already exist, as its clearly always instanciated. 
As a result the compiler should not instanciate the TypeInfo for 
SomeStruct but instead assume that it also already exists. By doing so 
it would never write the SomeStruct type info to the object file and the 
linker errors would go away.

I'm asking this because this behavior for type info generation turns out 
to be a problem for my dll-work.
-- 
Kind Regards
Benjamin Thaut
Jan 09
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 09, 2018 at 06:20:31PM +0100, Benjamin Thaut via Digitalmars-d
wrote:
 [...] The compiler should be able to figure out that the destructor of
 SomeOtherStruct must already exist, as its clearly always
 instanciated. As a result the compiler should not instanciate the
 TypeInfo for SomeStruct but instead assume that it also already
 exists.  By doing so it would never write the SomeStruct type info to
 the object file and the linker errors would go away.
 
 I'm asking this because this behavior for type info generation turns
 out to be a problem for my dll-work.
[...] AFAIK, originally the compiler had a similar behaviour when it comes to instantiating templates, but some time ago that was changed so that the relevant symbols were only generated if the module they originate from is currently being compiled. I think it will be a very good idea to implement something similar for this dtor case as well, if not for the entire typeinfo generation process. It will help to cut off more unnecessary linker dependencies and reduce the amount of executable bloat when linking in a library where not all symbols are actually used. T -- Turning your clock 15 minutes ahead won't cure lateness---you're just making time go faster!
Jan 09