Init symbols, TypeInfos (classes only) & vtables - unless defined in a
root module. For explicitly exported aggregates, or, with
`-fvisibility=public`, all aggregates.
As *the* way to access the IrType associated with a Type via its `ctype`
field. Most importantly, it makes sure all access is redirected to the
*unqualified* type's `ctype`, which allows to get rid of the 'multiple
types' workaround for aggregates in DtoType(). Those were e.g. hit for
`shared struct SpinLock`, where the struct's type includes the `shared`
modifier...
The semantics were almost identical, except for DtoIsTemplateInstance()
checking the specified Dsymbol and its parents, while isInstantiated()
starts from its parent and ignores the symbol itself.
After a quick glance, we seem to have fed it with {Aggregate,Func,Var}
Declarations only, so should be fine with the default front-end variant.
I.e., *define* templated symbols in each referencing compilation unit
when using discardable linkonce_odr linkage, analogous to C++.
This makes each compilation unit self-sufficient wrt. templated symbols,
which also means increased opportunity for inlining and less need for
LTO. There should be no more undefined symbol issues caused by buggy
template culling.
The biggest advantage is that the optimizer can discard unused
linkonce_odr symbols early instead of optimizing and forwarding to the
assembler. So this is especially useful with -O to decrease compilation
times and can at least in some scenarios greatly outweigh the
(potentially very much) higher number of symbols defined by the glue
layer.
Libraries compiled with -linkonce-templates can generally not be linked
against dependent code compiled without -linkonce-templates; the other
way around works.
Compiling the rt.util.typeinfo unittests leads to base-typed forward
declarations of built-in TypeInfos colliding with the init symbols for
their TypeInfo_* classes in rt.util.typeinfo.
We've already had a workaround for this in one place (typinf.cpp);
extend it to the other side as well (iraggr.cpp).
Also make sure to emit the TypeInfo metadata even if the IR symbol
already exists as init symbol.
And finally, keep init symbols of built-in TypeInfo classes mutable just
like any other TypeInfo, so that e.g. synchronized() can be used on the
implicit monitor.
LLVM already provides suited RAII helper types to restore the IRBuilder
state. [They sadly aren't movable, so I've had to wrap them in a
unique_ptr.]
While at it, also minimally revise debuginfo generation for functions.
Replace the stack of IRScopes, each with its own IRBuilder, by directly
tampering with the state of a single IRBuilder.
This seems like the most feasible way to account for a breaking change
in LLVM 11, disallowing IRBuilder from being copied.
Whenever we need an IR function, we'd better make sure it exists. Handle
that in DtoCallee(), by invoking DtoDeclareFunction() by default,
instead of the previous DtoResolveFunction() + DtoCallee() combo.
DtoResolveFunction() usually declares the function, but somehow doesn't
for abstract and body-less functions.
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.
