Returning null will crash just about any other glue layer code.
Ideally, we'd catch those during semantic analysis (glue layer
errors are always to be avoided due to speculative compilation),
but this at least avoids the segfaults.
An assert expression has a slightly different requirement: if the assertion holds then
the expression of the message is not evaluated. A destructor of a temporary variable must
not be called because the object was never constructed.
If the assertion does not hold and an exception is raised, then the destructor must be
called in a finally block.
This fixes a test failure in xtest46.d
This fixes a segfault with associative array literals of
arrays of associative array literals, which occured because
of arrayLiteralToConst not handling null values properly.
Ensuring that null pointers are handled correctly in all
toConstElem callers is much more error-prone than just
returning an LLVM undef, an error is emitted anyway.
The root of the problem is actually in the kludgly
implementation of AssocArrayLiteral::toElem, we should
revisit this at some point.
This unsfortunately more or less duplicates the code we have for
emitting ArrayLiteralExps, but with the different iteration
strategies, having a single implementation would wind up
even messier.
Unfortunately, no regression test case yet, as I found this deep
inside vibe.d.
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.
