No idea how to reproduce this, as it occurs within a 300 frame deep
call stack (nested typeinfo emission), and I couldn't get a smaller
test case so far.
An alternative fix would be to call the typinf.cpp functions that
emmiit the symbol directly instead of going through CodegenVisitor
(which then skips the TypeInfo because it is for a speculative
struct, so that the TypeidExp that wants to use it can't read the
global variable).
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 { ... }`.
This restores the previous TypeClass::builtinTypeInfo() logic that
always returns false for Tclass and puts back in a relevant FIXME
comment. This prevents a bunch of missing class TypeInfo definitions.
Includes all tagged with v2.067.0-b2. Does not includes latest druntime changes from ldc (head) branch.
This is known to be broken. I only merged the frontend stuff but did not try to compile something...
First merge of current development stream. Asm blocks are known to be broken.
DMD: 0c9f437bc24015707130ba42dc434d9cd58282fb
druntime: 86d49cfb3670904603df0cfdfe44c6fff565c0fc
Phobos: a8ca4f7964becac680af0eadbde05aa7d10fc338
The type should have already been resolved if the struct
itself is, but due to multiple-types-per-declaration issues
in DMD, this might not be the case.
GitHub: Fixes#470.
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.
