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.
