<div dir="ltr">How about this?<div><br></div><div><a href="https://github.com/D-Programming-Language/dmd/pull/1760">https://github.com/D-Programming-Language/dmd/pull/1760</a> <br></div><div><br></div><div>Kenji Hara</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/3/17 David Nadlinger <span dir="ltr"><<a href="mailto:code@klickverbot.at" target="_blank">code@klickverbot.at</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I'm still working on tracking down the last couple of LDC test suite<br>
regressions from 2.061 to 2.062. In one of the cases, the problem is<br>
actually in the frontend, even if it might not cause a visible bug<br>
for DMD.<br>
<br>
<br>
Consider this test case (reduced from xtest46):<br>
<br>
———<br>
mixin template DefineCoreType() {<br>
  struct Faulty {<br>
    static int x;<br>
    X164!() xxx;<br>
  }<br>
}<br>
<br>
mixin DefineCoreType!();<br>
<br>
mixin template A164() {}<br>
<br>
struct X164() { mixin A164!(); }<br>
<br>
———<br>
<br>
The issue is that if sd is the/a 'Faulty' declaration,<br>
((TypeStruct*)sd->type)->sym != sd – there seem to be two<br>
StructDeclaration instances around that both correspond to 'Faulty'!<br>
<br>
An easy way to see this is by adding an assertion for this to the end<br>
of StructDeclaration::semantic:<br>
<br>
———<br>
--- a/src/struct.c<br>
+++ b/src/struct.c<br>
@@ -655,6 +655,8 @@ void StructDeclaration::semantic(Scope *sc)<br>
         deferred->semantic2(sc);<br>
         deferred->semantic3(sc);<br>
     }<br>
+<br>
+    assert(static_cast<TypeStruct*>(type)->sym == this);<br>
 }<br>
<br>
 Dsymbol *StructDeclaration::search(Loc loc, Identifier *ident, int flags)<br>
———<br>
<br>
The commit in which this assertion first triggers on the above test<br>
case is 14d3c7535, which is a fix for a 2.061 regression, issue 9276.<br>
I'm not sure, though, if this piece of code is to blame, or if the<br>
root cause lies in the way the declaration copying for template<br>
mixins is handled.<br>
<br>
I would be glad if somebody could have a look at this (Kenji, maybe<br>
the issue is obvious to you?), as it wreaks havoc with LDC's codegeń<br>
(LDC needs type information all over the place, as the LLVM IR is<br>
typed, and was definitely written with the assumption of having<br>
a consistent AST to work with.)<br>
<br>
<br>
Similar issues have occured multiple times in the past; one almost<br>
identical problem is <a href="http://d.puremagic.com/issues/show_bug.cgi?id=8626" target="_blank">http://d.puremagic.com/issues/show_bug.cgi?id=8626</a>,<br>
but there have also been problems that later turned out to actually<br>
trigger DMD bugs as well (such as the inout nested struct mangling<br>
issue).<br>
<br>
As they are additionally quite time-consuming to track down, I have<br>
been thinking about introducing a śet of »AST validation« checks<br>
that are run before codegen and are activated by a compile time<br>
switch (for development and on the CI bots). What do you think? Any<br>
implementation suggestions?<br>
<br>
<br>
Thanks,<br>
David<br>
_______________________________________________<br>
dmd-internals mailing list<br>
<a href="mailto:dmd-internals@puremagic.com">dmd-internals@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/dmd-internals" target="_blank">http://lists.puremagic.com/mailman/listinfo/dmd-internals</a></blockquote></div><br></div>