This is as per DMD a54e89d, but has not been tested all too carefully
yet – there still seem to be issues with extern(C++) interfaces (see
test suite).
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.
This could happen when having e.g. a ClassReferenceExp in
addition to the default initializer. Unfortunately, I could
not easily distill a test case for this issue from a large
application I was working on.
Fixes ABI mismatch when e.g. padding a 28 byte union from a
20 byte member, where previously, an i64 would be emitted,
yielding a 32 byte LLVM struct size on ulong.alignof == 8
platforms.
Test case will follow on the 2.064 branch.
Adds some constructors and moves the code to the header file. Uses some of the new constructors.
A big problem with the source are the different strategies used for otherwise similar classes.
E.g. a IrField registers itself with the VarDeclaration. Same is required for IrParameter, but
in this case it is done by the caller.
This commit fundamentally changes the way symbol emission in
LDC works: Previously, whenever a declaration was used in some
way, the compiler would check whether it actually needs to be
defined in the currently processed module, based only on the
symbol itself. This lack of contextual information proved to
be a major problem in correctly handling emission of templates
(see e.g. #454).
Now, the DtoResolve…() family of functions and similar only
ever declare the symbols, and definition is handled by doing
a single pass over Module::members for the root module. This
is the same strategy that DMD uses as well, which should
also reduce the maintainance burden down the road (which is
important as during the last few releases, there was pretty
much always a symbol emission related problem slowing us
down).
Our old approach might have been a bit better tuned w.r.t.
avoiding emission of unneeded template instances, but 2.064
will bring improvements here (DMD: FuncDeclaration::toObjFile).
Barring such issues, the change shoud also marginally improve
compile times because of declarations no longer being emitted
when they are not needed.
In the future, we should also consider refactoring the code
so that it no longer directly accesses Dsymbol::ir but uses
wrapper functions that ensure that the appropriate
DtoResolve…() function has been called.
GitHub: Fixes#454.
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.
