Assumptions:
- class methods do not change the object's vtable pointer
- loads through vtable pointer are invariant (vtables are immutable throughout program life)
And use `IrTypeClass::getVtblType()` to get the vtable LLVM array
type, instead of deriving it from the `IrClass::getVtblSymbol()`
global (invoking that function may define the vtable!).
I've hit some compiler crashes for the Symmetry code base, on
Windows only. I guess the problem surfaced due to
`-link-defaultlib-shared`, which on Windows causes some vtables of
instantiated classes to be defined whenever accessing the vtable
symbol. I don't have a reduced test case unfortunately.
`NewExp.type` can apparently newly be a yet-unresolved `TypeIdentifier`.
Resolve it in that case to a `TypeClass` now.
Also defer the has-dtor check for the whole class hierarchy of the
*dynamic* type from that LDC-specific frontend addition to the glue
layer, as I'm not sure we can rely on `ClassDeclaration.dtor` having
been set at that time already.
I've chosen to keep storing a single extra LDC-specific *bit*
(`onstackWithMatchingDynType`) instead of storing the full dynamic
class type. While this slightly weakens the optimization (no
optimization for non-equivalent static/dynamic class types anymore),
it doesn't increase the AST node size. And I think almost all cases
use an equivalent type anyway (e.g., the DMD frontend itself only uses
`scope` class allocations with equivalent types).
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.
Invoke _d_newThrowable for exception allocation & initialization, and
increase the reference count in LDC-specific _d_throw_exception for MSVC
targets. Fixes runnable/test19317.d.
I noticed that an `align(N) class ...` seems to be totally ignored; i.e.,
it has no effect on `Type::alignment()` and neither on
`ClassDeclaration::alignsize()`.
I checked the paddings too (and the tests cover them as well); they seem
fine already, both inbetween header and payload (and for both D and C++
classes, the latter missing the monitor field) as well as inbetween base
payload and derived payload.
For -betterC and/or a minimal object.d without TypeInfo:
* Skip TypeInfo emission for classes and interfaces.
* Emit null as first vtable member.
Makes dmd-testsuite's {compilable,runnable}/minimal2.d work.
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.
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).
The dtors can be checked at compile-time; insert a runtime check for the
monitor before finalizing the stack-allocated class object via druntime
call.
See issue #2515.
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.
