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.
The integer initializer width mismatch issue should really be
fixed in the frontend, but is related to forward referencing
and thus hard to track down.
Also fixes an unlisted regression since the 2.061 merge, where
there would be a const(char*) vs. immutable(char*) mismatch
reported for some string constants.
GitHub: Fixes#378.
There might be still some pieces left here and there, and
there is certainly code that could be rewritten in a nicer
way with the 3.0 requirement out of the picture.
The check was never fully implemented. We need to look into
this again, as currently we fail with a fairly unintellegible
LLVM ICE (added as GitHub #).
1. Main include corresponding to .cpp file, if any.
2. DMD and LDC includes.
3. LLVM includes.
4. System includes.
Also updated a few include guards to match the default format.
The commit itself should be fine, but the more aggressive
inlining being done on the GC code (due to the gcbits functions
being in available in gc.gcx) seems to have uncovered a
misoptimization bug in LLVM (at least in 3.2) on x86, leading to
various unit tests failing in relase mode.
This reverts part of commit f02e4b1925.
A "statementsToo" flag was added to DMD, which disables inlining
of pretty much any functions that actually return a value – set it
to false for our purposes.
The other parts of the diff are just cosmetic.
