<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 13 Mar 2020, at 5:08, via cfe-dev wrote:</p>
</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">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)</p>
</blockquote></div>
<div style="white-space:normal">
<p dir="auto">To be precise, the only statement that <em>does</em> track the location<br>
of the semicolon is <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NullStmt</code>, and that’s only because it would<br>
otherwise have no associated source locations and so could not<br>
meaningfully implement <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">getSourceRange()</code>.</p>
<p dir="auto">The Clang AST serves several different masters. It’s understood<br>
that some of the information we track for the use of source tools<br>
isn’t very useful for compilation, and maybe the reverse as well.<br>
We do accept that this adds overhead to compilation. But we’ve<br>
generally drawn the line at storing delimiters because:</p>
<ul>
<li>vanishingly few clients of the AST need exact delimiter locations,</li>
<li>the clients that do care need them for vanishingly few AST nodes,</li>
<li>there are an awful lot of delimiters in a typical program, and
storing them all would eat a lot of memory, and</li>
<li>in most cases, it should be easy and cheap to retroactively find
those delimiters from the information we do track.</li>
</ul>
<p dir="auto">Furthermore, I think expressions are important to consider,<br>
because the practical limitations on finding the semicolon after<br>
an expression are exactly the same as finding it after <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">break</code>.<br>
Fortunately, most of these restrictions coincide with things that<br>
are mostly uninteresting to source tools: it’s possible that the<br>
semicolon could be inside a macro, but you probably can’t safely<br>
rewrite code around macro expansions anyway.</p>
<p dir="auto">Now, of course there should be one method that implements this<br>
scan instead of forcing it to be re-implemented again and again.<br>
That method can have a special case for <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">NullStmt</code>.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>