<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Sorry, I overlooked your point about the trailing comments. Yes, there are two issues: trailing comments and inclusion of semicolon -- my response was with regards to the semicolon.  Since there are a lot issues here, I've tried to break them down below.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">## Including semicolons (aka Expr vs Stmt)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">When an expression is used in a context expecting a statement and is trailed by a semicolon, the range will not include the semicolon.  If there are any comments between the expression and the semicolon those, too, will be left out.  If we had an ExprStmt, then one could imagine the expression range covering just the expression, but the statement range extending to include the comment and semicolon.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">## Including trailing comments</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The trailing comments issue seems to be consistent across syntactic forms (at least, the ones you've presented).  Add a trailing comment after a decl statement, eg.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  int x; // foo</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">and the range still ends at the semicolon. Similarly,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><div style="color:rgb(0,0,0);background-color:rgb(255,255,254)"><div><span style="color:rgb(0,0,255)">  if</span> (<span style="color:rgb(0,0,255)">true</span>) {} <span style="color:rgb(0,128,0)">// foo</span></div></div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">the range ends at '}'.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In general, associating comments is hard and it seems reasonable to me either way -- including or excluding.  I'll admit that it feels arbitrary that leading comments are included why trailing are excluded, but I'd venture a guess that this is caused by the parser. Morever, since it seems to be consistent, I think its ok, but should be documented clearly somewhere.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"># re: <span style="font-family:Arial,Helvetica,sans-serif">Is Expr the only Stmt that doesn’t include „it’s end“?</span></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I'd say no, with respect to trailing comments, but yes with respect to semicolons.  However, you could argue that it infects other statements as well, e.g.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">  if (...) foo();</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The range of the _if statement_ will not include the semicolon. So, it too does not include "it's end".</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">## unifyStmtRange()</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I'm all for this kind of thing and, in fact, think it's really the only good solution (that is, adding a layer atop the AST to compute things like this). I'm happy to review patches. Or, if you wait long enough, I'll probably get to this myself. :)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Cheers,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Yitzhak</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 26, 2020 at 4:53 PM Alexander Lanin <<a href="mailto:alex@lanin.de">alex@lanin.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="DE"><div class="gmail-m_937966520298567020WordSection1"><p class="MsoNormal"><span lang="EN-GB">Hi,<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">thanks, that’s interesting, but I’m not sure how this relates to trailing comments + semicolon?<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Why does it matter whether Expr is wrapped or not? It can contain comments in general. But doesn’t contain those at the end.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB">At least for such examples I find it strange: <a href="http://ce.steveire.com/z/KdXBDg" target="_blank">http://ce.steveire.com/z/KdXBDg</a><u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Is Expr the only Stmt that doesn’t include „it’s end“?<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Would it make sense to have some unifyStmtRange() in SourceCode.h with special handling for Expr which would extend it with (n x comment) + (optional comma or semi) [+ all the special cases I’m not thinking about right now]?<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Currently the check mentioned below always subtracts one char and then checks whether it’s a semicolon. Might be nicer to distinguish by isa<Expr>?<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Regards,<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB">Alex<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-GB"><u></u> <u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm"><p class="MsoNormal" style="border:none;padding:0cm"><b>Von: </b><a href="mailto:yitzhakm@google.com" target="_blank">Yitzhak Mandelbaum</a><br><b>Gesendet: </b>Mittwoch, 26. Februar 2020 16:40<br><b>An: </b><a href="mailto:alex@lanin.de" target="_blank">Alexander Lanin</a><br><b>Cc: </b><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><b>Betreff: </b>Re: [cfe-dev] Stmt.getEndLoc() vs semicolon</p></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif">Alexander,<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif">I agree that this behavior is rather confusing, especially to first-time users. The cause of the issue is that Expr derives from Stmt so that Exprs can appear directly in, for example, compound statements, rather than being wrapped in an explicit node to represent statements that consist only of an expression.  As far as I understand, this choice to avoid an explicit node had some (positive) performance implications for the AST when it was originally designed.  While I'd love to see this choice revisited, I think it would be a significant effort and don't expect it to happen.<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif">Instead, we tend to work around the issue.  For getting proper ranges of statements, you might find clang::tooling::getExtendedText/getExtendedRange meet your needs:<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><a href="https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Tooling/Transformer/SourceCode.h#L56" target="_blank">https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Tooling/Transformer/SourceCode.h#L56</a><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif">For declarations, the (just added!) getAssociatedRange might be even better: <a href="https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Tooling/Transformer/SourceCode.h#L39" target="_blank">https://github.com/llvm/llvm-project/blob/master/clang/include/clang/Tooling/Transformer/SourceCode.h#L39</a><u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif"><u></u> <u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif">Cheers,<u></u><u></u></span></p></div><div><p class="MsoNormal"><span style="font-family:Arial,sans-serif">Yitzhak<u></u><u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Tue, Feb 25, 2020 at 5:15 PM Alexander Lanin via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</p></div><blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm"><div><div><p class="MsoNormal"><span lang="EN-GB">Hello,</span></p><p class="MsoNormal"><span lang="EN-GB"> </span></p><p class="MsoNormal"><span lang="EN-GB">I’m having trouble with the locations returned by Stmt getEndLoc()/getSourceRange() and am wondering whether this is a bug/flaw:</span></p><p class="MsoNormal"><span lang="EN-GB">the returned location sometimes includes and sometimes excludes the semicolon in the end.</span></p><p class="MsoNormal"><span lang="EN-GB">This gets even more interesting when there are (multiple) comments before the semicolon, simply because the difference between the returned values gets even bigger.</span></p><p class="MsoNormal"><span lang="EN-GB">Here is an example showing how DeclStmt includes the semicolon, while CallExpr and BinaryOperator exclude the semicolon <a href="http://ce.steveire.com/z/TW3IAG" target="_blank">http://ce.steveire.com/z/TW3IAG</a>.</span></p><p class="MsoNormal"><span lang="EN-GB"> </span></p><p class="MsoNormal"><span lang="EN-GB">So Stmt behaves “completely differently” depending on it’s type, which is no way suggested by it’s interface.</span></p><p class="MsoNormal"><span lang="EN-GB">Wouldn’t it be better for Stmt-Users if it would always be the same?</span></p><p class="MsoNormal"><span lang="EN-GB">(Not sure whether it should always be included or excluded. It’s not even always a semicolon as in that 3rd foo() in the example)</span></p><p class="MsoNormal"><span lang="EN-GB"><a href="https://en.wikipedia.org/wiki/Liskov_substitution_principle" target="_blank">https://en.wikipedia.org/wiki/Liskov_substitution_principle</a></span></p><p class="MsoNormal"><span lang="EN-GB"> </span></p><p class="MsoNormal"><span lang="EN-GB">Here is one of the effects of this complexity for users of Stmt as they struggle to find that semicolon:</span></p><p class="MsoNormal"><span lang="EN-GB"><a href="https://bugs.llvm.org/show_bug.cgi?id=25970" target="_blank">https://bugs.llvm.org/show_bug.cgi?id=25970</a> / <a href="https://reviews.llvm.org/D16267" target="_blank">https://reviews.llvm.org/D16267</a></span></p><p class="MsoNormal"><span lang="EN-GB">Of course it’s fixable there, but that would imply working around the issue in multiple places.</span></p><p class="MsoNormal"><span lang="EN-GB"> </span></p><p class="MsoNormal"><span lang="EN-GB">Regards,</span></p><p class="MsoNormal"><span lang="EN-GB">Alexander Lanin</span></p></div></div></blockquote></div><p class="MsoNormal" style="margin-left:4.8pt">_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a></p><p class="MsoNormal"><u></u> <u></u></p></div></div></blockquote></div>