Open rikkimax opened 4 days ago
Class TypeInfos are emitted into their owning module/object file only, not on-demand in every referencing object file as other TypeInfos (and later uniqued during linking). So if the owning module is compiled with -betterC
, they aren't available.
We could change this behavior, although the -betterC
reason is IMO meh. ;) - I think the main reason for that decision is that class TypeInfos aren't optional/elidable as other TypeInfos, as the vtable refs it - at least for extern(D)
classes. And they are added to the owning module's ModuleInfo.localClasses
, for that Object.factory()
abomination.
You'd need duplicates in every referencing object file.
I was thinking that for C++ classes/interfaces they'll just nullify out since they may not be needed or appropriate to have.
Oh, druntime does need those D TypeInfos for extern(C++)
classes too, GC etc.
AA's, down casting and destructor calling by GC.
All things I don't need. If it is a binding which never gets compiled in it wouldn't need that either.
I've finally got around to using C++ classes in -betterC cross the shared library boundary.
As of ldc 1.38.0, what I've found is that the TypeInfo/Interface do not get emitted (expected) from within the shared library. However, on the executable side that is full D, it'll error given that it doesn't exist. I have not had this as an issue for any other TypeInfo.
I was not able to use my usual tricks via inline assembly to emit the data due to LLVM's type checking (I really wish I had a way to disable that for a symbol). In the end, the workaround I came up with was to template the entire class hierarchy (not good).
On that note, wouldn't the external path switch have helped here? Since if it was external, it may not have been compiled by the D compiler.