Created attachment 1426
Dustmited code that causes a segfault on dmd *.d
Not sure what is happening, the test case seems to be rather fragile, but the attached code is the smallest that dustmite seems to be able to come up with. I tried moving stuff around into fewer files but it often seems to hide the segfault. In any case the reduced case is broken, so after the segfault is fixed it will probably throw some more sane errors. Hopefully someone with more experience can figure it out!
dmd *.d
Segmentation fault
Comment #1 by ketmar — 2014-09-13T16:37:32Z
seems that compiler forgot to call `VarDeclaration::semantic()` on "isMatchingMaskField", but calls `VarDeclaration::semantic2()` for it. then it sees that `if (init && !toParent()->isFuncDeclaration())` is true and tries to call `init = init->semantic(sc, type, INITinterpret)`, but… but `type` is NULL here, 'cause no semantic() was done before.
with hacked in `if (!type) semantic(sc);` to the beginning of `VarDeclaration::semantic2()` compiler correctly complains that it cannot infer type.
but i don't understand semantic code yet, so let's wait for someone knowledgable to find why `semantic2()` was called without `semantic()` here.
Comment #2 by k.hara.pg — 2014-09-24T02:52:39Z
Reduced test case:
// [checkpoint.d]
module checkpoint;
import field;
auto createCheckpointMixins()
{
enum b = isMatchingMaskField!();
}
immutable checkpointMixins = createCheckpointMixins;
// [field.d]
module field;
template isMaskField() { import field; }
template isMatchingMaskField()
{
enum isMatchingMaskField = isMaskField!();
}
Command line:
dmd -o- checkpoint.d field.d
The route of semantic analysis that starts from the isMatchingMaskField!() instantiation.
TemplateInstance('isMaskField!T')->semantic()
TemplateInstance('isMaskField!T')->semantic2() <---[1]
Import('import imports.ice1365a;')->semantic2()
Module('imports.ice1365a')->semantic2()
VarDeclaration('imports.ice1365a.isMatchingMaskField!().isMatchingMaskField')->semantic2() <---[2]
[1] TemplateInstance::semantic() runs its semantic2() always. It was a fix for the issue 782, but it violates the semantic analysis invariance, that semantic2 should be done after semantic completed in each symbols.
[2] The type field is yet NULL, and then ICE happens.
(In reply to Kenji Hara from comment #2)
thank you for your explanation. i was trying to understand how early return from semanic() call will help the case when semantic() is not called at all, then i looked here and now it' clear.
Comment #5 by github-bugzilla — 2014-09-26T08:57:20Z