<div dir="ltr"><div dir="ltr">On Wed, Mar 25, 2020 at 5:08 PM Sam McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Mar 17, 2020 at 6:11 AM John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>




<div>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">Furthermore, I think expressions are important to consider,<br></p></div><div style="white-space:normal"><p dir="auto">
because the practical limitations on finding the semicolon after<br>
an expression are exactly the same as finding it after <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">break</code>.<br></p></div></div></div></blockquote><div>To spell this out a little more: formally in `foo();` there's an expression-statement which consists of a the call expression and the semicolon. But clang just uses the CallExpr node to represent both, and CallExpr obviously(?) shouldn't include the semicolon in its source range.</div></div></div></blockquote><div><br></div><div>Disclaimer: This is idle speculation, and I don't have any experience writing refactoring tools.</div><div><br></div><div>I wonder if we could store the delimiter locations in a memory efficient way by adding a second TrailingObject array to CompoundStmt. The overhead would be 4 bytes for every semicolon in the TU, which is potentially a lot when considering unused inline functions, but is not much when compared to the overhead of the Stmt node itself and the 8 byte Stmt* pointer already held in CompoundStmt.</div><div><br></div><div>There is of course the case of semicolon locations for non-compound statements (`if (cond) foo();`), but one could invent a new AST node for that case without wasting much memory.</div><div><br></div><div>It sounds like there are a lot of clang tools that use the lexer to search for semicolons. Would it help to store them this way instead?</div></div></div>