<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 9, 2015 at 5:26 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Stop using `DILocation::atSameLineAs()` to check whether two locations<br>
are equivalent.  This check is too weak: it ignores any column info that<br>
might be present, and ignores the scope/inlined-at chains.<br></blockquote><div><br>I don't think we can use the scope/inlined-at can be used here (but, as Eric said on IRC, we might not have testing for it) - we use the scope information to build the scope hierarchy in the debug_info, but it doesn't affect the line table at all. So we could have two debug locations with the same line/file/column but different scopes, yet the same basic block (something as simple as {} can introduce a scope without introducing a new basic block, of course, or a do-while loop would still have a contiguous range but be two basic blocks) and thus they'd coalesce to the same line table entry when they should be separate blocks, potentially.<br><br>Does that make sense?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Instead, just compare the pointers for equality.  If the pointers are<br>
different here, we'll get different entries in the line table already.<br>
<br>
I haven't updated testcases yet (there's one each failing in LLVM and<br>
clang that would need to be rewritten), but basically: is there any<br>
reason to add a discriminator if we'd *already* be getting different<br>
entries in the line table?  (Is there a broken consumer we need to<br>
support that relies on the discriminator field?)<br>
<br>
</blockquote></div><br></div></div>