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