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

[Danny Arends]

Hey Guys,

Working on my [3D engine](https://github.com/DannyArends/DImGui), 
I ran into an issue when updating the compiler 2.110 -> 2.112 
with the way that the code is structured. I am not a compiler 
person, or someone who deals with intricacies of linkage, but 
together with Claude I was able to reduce the issue to a minimal 
example. The issue itself doesn't cause too much issues (I can 
code around it) but it forces me to maintain C-code shims for 
compiler intrinsics when using 2.112, versus not needing to do 
this in 2.110...

Since the project compiles on Window, Linux this adds a minimal 
amount of C shim code, but this might grow in the future due to 
having more external libararies imported.

#### Issue and changes

Since 2.112, referencing the `TypeInfo` of a `struct` defined in 
an **imported** (not command-line) ImportC module fails at link 
with an undefined `RTInfoImpl` instance. Worked on 2.110 (didn't 
test 2.111).

#### Minimal repro (no external libs)

`minic.c`:

```c
struct S { long a; void *b; void *c; long d; void *e; long f; };
```

`mini.d`:

```d
import minic;

void main() { auto ti = typeid(S); }
```

Build the same way dub does — compile to an object, then link 
separately:
```shell
dmd -c mini.d -I. -of=mini.o
dmd mini.o -of=mini
```

undefined reference to object.RTInfoImpl!([48, 22]).RTInfoImpl
referenced from TypeInfo_S3__C1S.__init

#### What seems to be happening

dmd emits the C struct's `TypeInfo.__init` referencing 
`RTInfoImpl!([size, ptrBitmap])`, but the instance itself is 
**not emitted** in this case. From the object symbols, it only 
appears to be emitted as a side effect. So:

- A struct only reached via `typeid` / plain use (no AA/array 
template instantiated) → `RTInfoImpl` stays undefined → link 
error.
- A struct used as an AA key/value or array element → the 
AA/array template instantiation emits the instance → links fine.
- Pointerless structs use `rtinfoNoPointers` (no per-type 
instance) → never affected.

`nm` on the object confirms it — the instance is `U` (undefined):

U _D6object__T10RTInfoImplVAmA2i48i22ZQyyG2m

Structs whose `[size, bitmap]` layout happens to match one 
druntime already instantiates link by coincidence?; unusual 
layouts (like the `[48, 22]` above) don't.

#### Workaround (and its cost)

Putting the `.c` file on the command line (so the ImportC unit is 
compiled, not just imported) emits the `RTInfoImpl` and links 🥳. 
But full compilation then lowers the C headers' `static inline` 
bodies, which then reference compiler intrinsics ImportC doesn't 
implement. Several intrinsics such as `__builtin_clz` (GCC/Clang) 
and `_BitScanReverse` (MSVC), each of which now need to be 
maintained using hand-written stubs.

#### Questions

1. 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)?
2. 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?

**Environment:** DMD 2.112.0. The minimal repro fails to link on 
Linux (glibc 2.31, ld). On Windows (MSVC) the full project 
reproduces the same undefined `RTInfoImpl` errors, but this 
minimal repro links there. Possibly COMDAT/weak-symbol handling 
differs, or the `long`-sizing above; I haven't fully reduced the 
Windows case.