[PATCH] Store paren locations in IfStmt, WhileStmt, SwitchStmt.

Abramo Bagnara abramo.bagnara at gmail.com
Fri Nov 21 10:18:39 PST 2014

Il 02/10/2014 00:19, Richard Smith ha scritto:
> On Wed, Oct 1, 2014 at 3:12 PM, Alexander Kornienko <alexfh at google.com
> <mailto:alexfh at google.com>> wrote:
>     >>! In D5528#5, @doug.gregor wrote:
>     > In non-macro cases, one can extract the locations of the parentheses using the lexer. Personally, I don't think the benefits of being able to extract the locations of the parentheses efficiently or in the macro cases outweigh the disadvantages of bloating the AST further.
>     For the context: this patch resulted from the discussion on D5395.
>     I understand your concerns about bloating the AST. Some locations
>     can be relatively easy found by re-lexing small parts of the input.
>     One problem with this approach is that everyone who needs these
>     locations spends time looking for a way to get them and then writing
>     their own implementation. Is there a document or a comment
>     describing the high-level approach to what is considered worthy
>     storing in the AST?
>     Also, it may be reasonable to add utility methods in the AST classes
>     (or free-standing functions in clang/AST headers) for retrieving
>     some less frequently used locations of syntactic constructs in
>     non-macro cases (e.g. WhileStmt::findRParenLoc() which would find
>     the first non-comment token after getCond()->getLocEnd()). What do
>     you think?
> At the least, we should provide a version of
> Lexer::findLocationAfterToken that finds the location *of* the token,
> rather than skipping past it.
>     And while you're here, one more question related to D5395:
>     what is the reason why the statements ending with a semicolon do not
>     include the semicolon in their source range (with exception of the
>     NullStmt)? Is it feasible to extend the source range to include it?
>     (and what would you expect to break in this case?)
> Perhaps it's time to add an ExprStmt to represent an
> expression-statement, along with the location of its semicolon.

This would be fantastic and much needed. It would also permit to solve
current defect where the end source range of a Stmt is considered
without the final semicolon (with the weird exception of NullStmt)
despite what the standard grammar states.

I guess that this is due only to the need to be congruent with source
ranges of Expr statements where the semicolon is not trackable.

The addition of ExprStmt would solve everything.

Abramo Bagnara

More information about the cfe-commits mailing list