Making it obvious which of the two operations is performed, reducing
call args and making sure a global isn't defined multiple times via
`defineGlobal()`.
The only [intended] functional change is in gen/trycatchfinally.cpp,
where I inserted a check for an existing __cpp_type_info_ptr global when
emitting a catch for C++ exceptions.
The previous check wouldn't check intermediate aggregates for static-ness,
that was one problem. The other was the assertion that the outer function
can be reached as long as there are no static functions inbetween, which
isn't always the case, as issue #1864 clearly shows, which is resolved by
this.
We only needed that findLvalueExp() thing to 1. skip over casts and 2. to
use a (bin)assign's lhs instead of the (bin)assign's result.
Well, by making sure most (bin)assign expression actually return the lhs
lvalue, we don't have this problem anymore and only need to skip over casts
to get to the nested lvalue.
This gets rid of a hacky workaround and brings our AST traversal order
back to normal again.
* Introduce a DRValue base class to be able to discriminate between
DLValues and DRValues (e.g., function parameters).
* Let DValue::getRVal() return each DValue's value as DRValue.
This allows to convert a DLValue to a DRValue, a snapshot of the
lvalue's current state, while retaining the D type, something we've
previously lost when returning the low-level rvalue directly.
* Let the DtoR/LVal() helpers be the only way to convert a DValue to a
low-level value.
The relationship between them is at best tenuous; DVarValue should
probably be renamed to DLValue and is used right now to describe
a general lvalue, of which variables are just one example.
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 { ... }`.
Starting with LLVM 3.7, linkage and COMDAT are 2 different concepts.
This means that LinkageODROnce does not put the object into a COMDAT.
On Windows this resulted in linker error messages.
This PR places all template functions, TypeInfo objects and other
objects into a COMDAT.
Never generates any landing pads or invoke instructions right now
for simplicity. The code for emitting them will be added back in
the next step.
The "after..." blocks without any precedessors remain for now, as
we need a clean way to suppress any codegen for that block (but
not new blocks, which might resolve labels) before tackling that
one.
Builds druntime/Phobos on OS X x86_64 (albeit without EH, of course).
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).
