I.e., not in their owning CU if unused therein, but in all referencing
CUs instead, as linkonce_odr. The special member functions are still
only and unconditionally emitted in the owning CU.
Analogous to ClassInfos, incl. normal linkage (external for non-
templates, weak_odr for templates).
This enables to get rid of frontend logic wrt. whether to add
TypeInfoStructDeclarations to a module's members tree - previously,
it was defined as linkonce_odr in the owning module and each referencing
module (unless speculative) - and related extra semantic and codegen for
the special member functions.
I've gone a bit further and moved the entire TypeInfo emission for LDC
to the codegen layer; no TypeInfoDeclarations are added to the module
members anymore. Whenever we need a TypeInfo symbol during codegen, it
is declared or defined, and we don't need to rely on brittle frontend
logic with speculative-ness complications.
This might slightly increase compilation speed due to less emitted
TypeInfos and functions (possibly less work for the linker too).
A slight drawback is that the job of stripping unused struct TypeInfos
is fully delegated to the linker, as the TypeInfo is guaranteed to end
up in the owning object file due to no linkonce_odr.
Another theoretical drawback is that the optimizer can definitely not
inline xtoHash/xopEquals/xopCmp/xtoString/xdtor[ti]/xpostblit function
pointer indirections in non-owning CUs without LTO (neither the pointers
nor the special member functions are defined anymore).
These (public) members are probably hardly used directly though, and
instead used by the virtual TypeInfo_Struct methods equals/compare/
getHash/destroy/postblit, which are exclusively defined in druntime's
object.o (incl. the TypeInfo_Struct vtable) and aren't cross-module-
inlined anyway (without LTO).
Re-emitting the struct TypeInfos (and optionally the special member
functions too) into each referencing CU could be handled in our codegen
layer, which should be much simpler and more robust than the upstream
scheme.
Surfacing now as #3486 added a corresponding assertion.
I've tested this with an older vibe-d v0.8.6 lying around on my box.
The assertion was hit for the TypeInfo of a nested struct:
3c7ae13989/http/vibe/http/router.d (L570-L574)
I wasn't able to quickly reduce it to a stand-alone testcase and am
reluctant to put any more effort into this.
I've also compared against the current DMD implementations, to make sure
we are in sync.
DMD doesn't populate `TypeInfo_Class.m_offTi` either. This seems like a
leftover of some unimplemented idea (the LDC commit introducing the
CMake option is from 2008); the normal `TypeInfo_Class.interfaces` array
contains the offsets nowadays.
Incl. getting rid of the dependence on an associated
TypeInfoStructDeclaration, which was only really needed for the mangled
name of the global.
Also slightly revise metadata generation.
Emulation for @weak global variables is still left out but should be
analogous.
The test adaptations are mostly a revert of 3893840f. The testcase has
shown that @weak hasn't worked properly for ELF (linker apparently
prefers the version in the 1st object file, independent of whether it's
weak or not), because the functions are emitted in COMDATs.
clang emits COMDATs for templates and inline functions only, not for
regular functions.
The TypeInfo may need an extern(D) wrapper accounting for ABI
differences wrt. extern(C++) dtor implementations.
This fixes `runnable/cppa.d` for 32-bit x86 targets.
Making it obvious which of the two operations is performed, reducing
call args and making sure a global isn't defined multiple times via
`defineGlobal()`.
The only [intended] functional change is in gen/trycatchfinally.cpp,
where I inserted a check for an existing __cpp_type_info_ptr global when
emitting a catch for C++ exceptions.
Not all type declarations yet (e.g., some TypeInfo subtypes are still
accessed directly), but those already wrapped as LazyType in the
gen/runtime.cpp module (with check and proper error msg in case object.d
doesn't contain a required declaration).
Use the real LL type representing the TypeInfo (sub)class directly and
from the beginning, i.e., already for the declaration, instead of
building an extra LL struct type (firstly opaque, then finalized when
defining the TypeInfo via RTTIBuilder).
To get this to work in all cases, the dummy TypeInfo for opaque structs
is now a complete TypeInfo_Struct, with all 11/13 fields zero-
initialized. Previously, it was a special TypeInfo (no extra
TypeInfo_Struct fields) with TypeInfo_Struct vtable, something which DMD
also emits.
Also refactor the RTTIBuilder finalize() interface - e.g., don't set the
linkage there (had to be reverted for ModuleInfos) and only take the
global variable to be defined. Cast the field initializers if required,
e.g., null pointers to appropriately typed function pointers for
TypeInfo_Struct etc.
Improve robustness for TypeInfos of speculative types by only eliding
their TypeInfo definition, not the declaration of the LL global
altogether.
`DtoTypeInfoOf()` expects the LL global to be created and otherwise
fails with an assertion or segfault (e.g., issue #2357). So now only
linker errors should result in case the TypeInfo definition is missing.
Also normalize the calls to `DtoTypeInfoOf()` and revise the following
pointer bitcasts, as the LL type of forward-declared TypeInfo globals
may be opaque.
Instead of letting our old copy silently go more and more out-of-sync.
In this case, we missed the upstream fix wrt. skipping the declaration of
ClassInfos for speculative class types.
There are 2 noteworthy functional changes for function
`getOrCreateTypeInfoDeclaration()`:
1) The old version always overwrote `torig->vtinfo` with `t->vtinfo` when
declaring a new TypeInfo, whereas upstream's `genTypeInfo()` only sets
it if it was null before.
2) The old version called `semanticTypeInfo()` during a semantic pass,
upstream doesn't.
The LDC-specific exception for class types in `builtinTypeInfo()` is still
required.
Fixes dmd-testsuite's runnable/b16278.d.
The part needing most attention was ddmd.root.ctfloat, ddmd.target (incl.
gen/target.cpp) and ddmd.builtin. The front-end is now prepared for
elaborate compile-time floating-point types to allow for proper cross-
compilation.
This version still uses the host's `real` type for compile-time reals,
except for MSVC hosts, which still use 64-bit doubles (when compiled with
DMD host compiler too).
Some other changes:
* semantic*() of Statements extracted from statement.d to statementsem.d
* mangle() -> mangleToBuffer()
* Identifier::string -> toChars()
* Token::float80value => floatvalue
* Dsymbol::isAggregateMember() => isMember()
* BoolExp is no more
* ddmd.root.ctfloat: LDC-specific CTFE builtins
Fields `m_arg{1,2}` are only declared for x86_64 targets, so there was a
size mismatch. In the best case, this lead to `m_RTInfo` containing a
TypeInfo pointer instead of the `hasPointers` flag in the least
significant bit (=> no `hasPointers`). `hasPointers` is also specified in
`m_flags` though, so I'm not sure `m_RTInfo` is actually used.
