<div dir="auto"><div dir="auto">While it most likely won't solve all cases, there's Lexer::getLocForEndOfToken. It can be used to create a range that grabs the semi at the end - assuming there is one... having to be context-sensitive on when we try grabbing it is still a requirement.</div><div dir="auto"><br></div><div dir="auto">I do vaguely remember seeing it used in Tidy in a few places.</div><div dir="auto"><br></div><div dir="auto">But other tools seems to have an issue with this too, looking at the docs for getLocForEndOfToken, it shows arcmt has a method named findSemiAfterLocation.</div><div dir="auto"><br></div><div dir="auto"><br></div>off {<div dir="auto">  I'm in awe that extending Stmt classes worked. I tried something similar recently and it just exploded in my face.</div><div dir="auto">}</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Mar 2020, 10:08 via cfe-dev, <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" rel="noreferrer">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
currently Stmt getEndLoc returns slightly different results depending on Stmt type.<br>
Specifically DoWhile, GotoStmt, ContinueStmt, BreakStmt, ReturnStmt, AsmStmt and SEHLeaveStmt do not track the location of the mandatory semicolon at the end.<br>
(Expr is out of scope of this mail thread)<br>
<br>
This is not really a high priority problem, but it makes some replacements in clang-tidy unnecessarily difficult.<br>
Currently one has to differentiate by statement type and then parse past it's end skipping comments until a tok::semicolon within checkers.<br>
Of course based on the last Stmt in case of children like an IfStmt without parenthesis.<br>
<br>
However I feel this is a kind of an ugly workaround and Stmt.getEndLoc() should just return the proper end location for all statements incl all mandatory tokens.<br>
To accomplish this the beforementioned statements require a new SourceLocation member.<br>
My assumption is that this has little impact on memory & cache-locality, since those are not really high-occurrence statements - but I'm no expert.<br>
Proof of concept is available here: <a href="https://reviews.llvm.org/D76108" rel="noreferrer noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D76108</a> (it has many many flaws, don't take it as ready for any kind of review).<br>
<br>
Does it make sense to continue that way?<br>
<br>
Regards,<br>
Alexander Lanin<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" rel="noreferrer noreferrer" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>