Re: Bug in TypeInfo generation?

[H. S. Teoh via Digitalmars-d]

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!

Bug in TypeInfo generation?

[Benjamin Thaut via Digitalmars-d]

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