[cfe-dev] Extend Stmt with proper end location?

John McCall via cfe-dev cfe-dev at lists.llvm.org
Mon Mar 16 22:11:23 PDT 2020


On 13 Mar 2020, at 5:08, via cfe-dev wrote:
> currently Stmt getEndLoc returns slightly different results depending 
> on Stmt type.
> Specifically DoWhile, GotoStmt, ContinueStmt, BreakStmt, ReturnStmt, 
> AsmStmt and SEHLeaveStmt do not track the location of the mandatory 
> semicolon at the end.
> (Expr is out of scope of this mail thread)

To be precise, the only statement that *does* track the location
of the semicolon is `NullStmt`, and that’s only because it would
otherwise have no associated source locations and so could not
meaningfully implement `getSourceRange()`.

The Clang AST serves several different masters.  It’s understood
that some of the information we track for the use of source tools
isn’t very useful for compilation, and maybe the reverse as well.
We do accept that this adds overhead to compilation.  But we’ve
generally drawn the line at storing delimiters because:

- vanishingly few clients of the AST need exact delimiter locations,
- the clients that do care need them for vanishingly few AST nodes,
- there are an awful lot of delimiters in a typical program, and
   storing them all would eat a lot of memory, and
- in most cases, it should be easy and cheap to retroactively find
   those delimiters from the information we do track.

Furthermore, I think expressions are important to consider,
because the practical limitations on finding the semicolon after
an expression are exactly the same as finding it after `break`.
Fortunately, most of these restrictions coincide with things that
are mostly uninteresting to source tools: it’s possible that the
semicolon could be inside a macro, but you probably can’t safely
rewrite code around macro expansions anyway.

Now, of course there should be one method that implements this
scan instead of forcing it to be re-implemented again and again.
That method can have a special case for `NullStmt`.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200317/63617bc1/attachment-0001.html>


More information about the cfe-dev mailing list