We already generated the memsets for zeroing the padding,
but because we relied on the native LLVM type allignment
where possible instead of generating explicit padding
values, LLVM did not always copy those bytes around (e.g.
when spilling/reloading registers).
The previous approach was to add i64, i32, i16, i8 members depending
on alignment and required space. This seems to cause several problems.
Solution is to use a byte array. This makes to code more compact, too.
Fixes issue #989.
The `union` is not created as packed type. This seems to create problems with the default initializer:
struct Foo
{
static union Bar
{
bool b;
ulong l;
}
Bar bar;
}
static this()
{
Foo foo = Foo();
}
creates an error. If you change the order inside the union
static union Bar
{
ulong l;
bool b;
}
then the code works.
Also cleans up the creation of the additonal zeroes for the initializer.
If there are gagged errors then `fatal()` is called in `irtypeaggr.cpp/AggrTypeBuilder::addAggregate()`.
In this case `fatal()` should only be called is there is no error gagging and an overlapping initialization
has been detected.
This fixes a regression introduced in caa2f15c8a. The IrDsymbol
metadata is obviously reset in between modules, while IrTypes
are not. Thus, we can never set symbol metadata when resolving
types, as the symbol data will be wrong in all modules following
the one where the type was first resolved.
GitHub: Fixes#739.
This avoids problems where we would codegen children of an
"inner" template instantiation (i.e. a member of a non-template
aggregate in another module) because we have no way to know the
outer (declare-only) entity exists in the respective
mustDefineSymbol invocation.
An example for this are the std.typecons.RefCounted internals of
std.file.DirIterator, as used from std.datetime and other modules.
This is not only inefficient, but also causes linking issues due
to attribute inference for these functions not having run yet
(and consequently the mangled name being different from the
actual definition).
This not only reduces code duplication, but the unification
also enables code a la StructLiteralExp to handle classes
(for CTFE class constant support in 2.063).
This is just to improve clarity, as it was rather non-obvious
what of the code also applied to classes before.
IrTypeAggr::createInitializerConstant would currently belong in
IrTypeStruct, but this will be refactored anyway.
