Bug 10831 – using typeid in CTFE or type inference in imported file adds link dependency

Considering two modules test.d and imp.d: ////////////////////////// module test; import imp.d; void main() {} ///////////////////////// module imp; struct S { int x = 2; } static assert(typeid(S)); ///////////////////////// Compile with "dmd test.d" works fine. However building with debug information "dmd -g test.d" yields: OPTLINK (R) for Win32 Release 8.00.13 Copyright (C) Digital Mars 1989-2010 All rights reserved. http://www.digitalmars.com/ctg/optlink.html test.obj(test) Error 42: Symbol Undefined _D3imp1S6__initZ --- errorlevel 1 The same happens with type inference: ///////////////////////// module imp; struct S { int x = 2; } auto ti = typeid(S); ///////////////////////// This is caused by some operations adding TypeInfo instances to the object file that reference the static initializer of a type. This initializer is only generated with the type declaration, though. The normal link strips the COMDAT with the TypeInfo, but the debug info is not split per COMDAT, so it drags the offending symbol back in. Some more operations that implicitely use typeid and probably exhibit this behaviour when executed during CTFE aswell: - struct postblit and dtor - array.dup and idup - array.sort

Actually this fails on Win64 even without debug info: >dmd -m64 test.d test.obj : error LNK2001: unresolved external symbol _D3imp1S6__initZ test.exe : fatal error LNK1120: 1 unresolved externals I guess it also fails on other platforms.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17604 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB