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
Now with *almost* working EH codegen. Does not compile Phobos yet
because we run into the "instruction does not dominate all uses"
issue when an r-value result of toElemDtor is used and we need to
run cleanups in between. Should easily be fixed by promoting those
values to allocas.
Most of the changes outside of ir/irfunction.{h, cpp} are just
because CreateCallOrInvoke moved locations. I took the
opportunity to also make use of the different arg count
overloads where possible.
The front-end uses a single bool variable as gate for all destructors
(by replacing each dtor expression by `gate || dtor()`).
This flag is set at the end of the argprefix chain of CommaExp.
So when no exception occurs in argprefix, the dtors aren't invoked in
the inserted finally block.
Right after the finally block we have the call to NewExp's ctor, which
will take care of destructing its parameters.
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.
Since the change to the symbol emission strategy, a lot of the
previous attempts to derive the linkage for a symbol from its
AST node has been superfluous. This cleans up all the related
code, as it is really not doing much anymore.
The code to opportunistically internalize symbols is now gone
entirely. It was commented out anyway due to problems with
making it work reliably in the face of the not-so-stable
structure of the AST we get from the frontend (regarding the
modules certain symbols end up in). But in any case internal
linkage woudl also be troublesome for cross-module inlining,
so I gave up on making this work for the time being.
The only (minor) change in the emitted code should be in
.offTi generation, which is untested and disabled by default
anyway (GENERATE_OFFTI).
The remaining ones should also be easy to remove with a
closer look at the situation.
Ideally, we would get rid of all of them at some point and
use safe wrapper functions for accessing the IrDsymbol
associated with a given declaration (which would emit the
declarations on the fly if not already present).
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.
