Fix #4779 - C++ classes need TypeInfo

[rikkimax]

I have literally no idea if this is even going to work.

I only managed to find the location that needed changing thanks to GH's web copilot (and promptly burned through an entire month of free credits lol).

[rikkimax]

Ok yeah I'm lost.

ld: error: duplicate symbol: core.internal.gc.impl.proto.gc.ProtoGC.__interfaceInfos
>>> defined at cast_.d
>>>            runtime/objects-debug-shared/core/internal/cast_.o:(core.internal.gc.impl.proto.gc.ProtoGC.__interfaceInfos)
>>> defined at gc.d
>>>            runtime/objects-debug-shared/core/internal/gc/impl/proto/gc.o:(.data.rel.ro._D4core8internal2gc4impl5protoQo7ProtoGC16__interfaceInfosZ+0x0)

[rikkimax]

Hmm, I set linkage onto getInterfaceArraySymbol but that didn't clear up that linker error.

[rikkimax]

Should probably add a couple of interfaces to verify that they work. One for parent, one for child both in -betterC file.

[rikkimax]

Added the interfaces.

Also checked that the macos failure isn't caused by me, it's in other PR's.

[kinke]

You're now switching to the emit-into-every-referencing-object-file TI emission scheme for all classes, and all symbols they reference. Not restricting it to C++ classes, nor as the hacky 'solution' this is for interoperating with separate betterC binaries not exporting any TypeInfos. So this would affect OO code emission quite considerably, and badly as in bad code bloat.

Have you considered making your betterC libraries a bit more fine-grained, disabling all the rest except for leaving TypeInfos enabled? I don't expect it would work out of the box, presumably needing some LDC adaptations, but it might be a better solution for the special problem in #4779.

[rikkimax]

You're now switching to the emit-into-every-referencing-object-file TI emission scheme for all classes, and all symbols they reference. Not restricting it to C++ classes, nor as the hacky 'solution' this is for interoperating with separate betterC binaries not exporting any TypeInfos. So this would affect OO code emission quite considerably, and badly as in bad code bloat.

I can gate it at the end, although I am hoping by not gating it that it'll maybe find some cases with the help of the D classes in testsuite that I won't think of.

And yes, I am aware of a testsuite change for D classes that's easily undone.

Have you considered making your betterC libraries a bit more fine-grained, disabling all the rest except for leaving TypeInfos enabled? I don't expect it would work out of the box, presumably needing some LDC adaptations, but it might be a better solution for the special problem in #4779.

That would be a valid solution for me, and so is the one I ended up with by templating classes.

However the point of ProjectSidero is three fold:

1. To discover under-the-hood issues
2. Fix issues found
3. Learn about standard library creation

By implementing what amounts to a standard library, I can verify if it's a problem worth solving. If I can do it without a fix reasonably well, so can others.

In this case I have an example of where somebody tried to mix full D and -betterC together with C++ classes and failed due to linker issues. And that is Andrei with dmd.common.

Given that I could confirm that it's a problem worth solving, and I have Andrei as an example, I am confident this needs fixing.

[rikkimax]

Now that I am thinking about gating beyond simply keeping it an option for later:

TypeInfo is really only needed for C++ classes in the following cases (that I can think of):

• Child class
• typeid
• new, due to templated hooks this is now typeid problem
• AA's which come under new
• Reference by another TypeInfo
• D variadics

If it were gated upon reference by another TypeInfo, typeid and D variadics, that may make it PAYG enough to remove the code bloat issues. Would also work for structs.

I suspect implementing it may be more than what I can do, though ;)