On Wed, Oct 1, 2014 at 3:12 PM, Alexander Kornienko <[email protected]> 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. > http://reviews.llvm.org/D5528 > > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
