The front-end fills in missing init expressions (except for the nested
context pointer in most cases), so there are no implicitly initialized
fields for dynamically initialized struct literals.
The front-end is also supposed to make sure there are no overlapping
initializers by using null-expressions for overridden fields, but doesn't
in some cases (DMD issue 16471).
Instead of preferring the first one in lexical field order, now use the
lexically last one to mimic DMD.
The previous code iterated over the fields in lexical order and ignored
the initializer for a field if there were earlier declared fields with
greater offset (and an initializer expression), which is wrong for
anonymous structs inside a union:
union {
struct { int i1; long l = 123; }
struct { int i2; int x = 1; }
}
`x` was previously initialized with 0 (treated as padding).
By refactoring IrAggr::addFieldInitializers() and making it use an
extended and refactored AggrTypeBuilder::addAggregate().
AggrTypeBuilder::addAggregate() can now optionally detect alias fields
in unions (same offset and LL type as a dominant union field) and add
those to the variable-to-GEP-index mapping.
These alias fields can then be indexed directly with a GEP instead of
resorting to casting the pointer and applying the byte offset.
Also adds the CMake infrastructure to compile and link the D source files.
The build is partially broken:
- A few files in Phobos and druntime do not build
- MSVC build is broken because of unresolved symbols involving reals
Trying to get the alignment right by using the first non-default one
in the following order of descending priority:
VarDeclaration::alignment [variables only of course]
Type::alignment()
Type::alignsize()
This fixes `align(x) struct S { ... }`.
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.
