<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 16, 2013 at 9:13 PM, Manman Ren <span dir="ltr"><<a href="mailto:manman.ren@gmail.com" target="_blank">manman.ren@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Wed, Oct 16, 2013 at 2:00 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Wed, Oct 16, 2013 at 1:33 PM, Manman Ren <span dir="ltr"><<a href="mailto:manman.ren@gmail.com" target="_blank">manman.ren@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br>patch looks fairly obvious/trivial<br>
<br>Have you tried any of the test cases I've described (special members, nested types, and member templates - all used across CUs so an earlier CU has the type definition and a latter one has one of these extra members)? I'd like to see test results for these before we progress. <br>



</div></div></div></div></blockquote><div><br></div></div><div>Yes, templates and nested types where we have two MDNodes for the same class, and one has an extra member.</div></div></div></div></blockquote><div><br></div>


</div><div>Could you include the tests (or at least in a separate patch if you think they're so uninteresting as to possibly not be needed with your change)?<br><br>I'd be interested to see how you constructed/tested them, which order the CUs came in, how the mismatch was resolved, etc.</div>

</div></div></div></blockquote><div><br></div></div><div>Sure, I can add the testing cases in a separate patch.<br></div></div></div></div></blockquote><div><br></div><div>I'd like to see the tests before the patch is committed (at which point they might as well be committed along with the patch).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>They work fine with the patch (no assertion failure).</div>


</div></div></div></blockquote></div><div><br>I'm interested in more than just the absence of assertions. (or are you referring to the kind of assertion machinery we've touched on in this thread but I haven't seen your code for - in which we keep a mapping of assumptions and verify those assumptions when a DIE is added to its parent and the assumption is resolved?)<span><font color="#888888"><br>

</font></span></div></div></div></div></blockquote></div><div><br>I was referring to the assertion that when emitting ref4, the DIE and the referenced DIE belong to the same CU (i.e. we made the right<br>decision about the reference form inside addDIEEntry).</div>
</div></div></div></blockquote><div><br></div><div>But none of your patches have the code necessary to check this assertion while not using a worklist, do they? so how does "no assertion failures" mean "we used the right form"? </div>
</div></div></div>