[Bug?] ImportC: undefined RTInfoImpl for imported C struct's TypeInfo on 2.112

[Danny Arends]

On Friday, 3 July 2026 at 01:40:20 UTC, Richard (Rikki) Andrew 
Cattermole wrote:
> On 03/07/2026 7:06 AM, Danny Arends wrote:
>> # Is import-only |RTInfo| emission expected to work in 2.112, 
>> or is compiling the ImportC unit now required by design 
>> (fallout from the AA/ array-hook templatization)?
>
> No.
>
> If you don't compile a file, you don't get the symbols that it 
> provides.
>
> This is true for D, as it is C++.
>

Understood on external symbols, the SDL/Vulkan functions link 
fine from their libs compiled by gcc/clang; that was never the 
issue. The undefined symbols are dmd's own RTInfoImpl/TypeInfo 
for the C structs — D metadata that has no external source, so it 
can only come from compiling the ImportC unit.

My includes.c is pure #include glue (no code of its own), yet I'm 
forced to compile it as a full TU solely to obtain that D 
type-info.This then also lowers the headers' static inline bodies 
and pulls in the __builtin_clz/_BitScanReverse intrinsics ImportC 
doesn't implement.

Is there a way to get dmd to emit the type-info for imported C 
structs *without* compiling their inline bodies / or is compiling 
the whole TU (intrinsics and all) the intended cost of using 
typeid/GC on ImportC types?


>> # Is this the same as fixed Issue 10442 <https://bugzilla- 
>> archive.dlang.org/bugs/10442/> ("RTInfo generation can fail 
>> for structs defined in imported modules"), incompletely fixed?
>
> I don't think so. It never should have worked with dmd's 
> current generation model for TypeInfo.