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

Manuel Klimek klimek at google.com
Thu Oct 2 00:36:22 PDT 2014


On Thu Oct 02 2014 at 1:46:55 AM Eli Bendersky <eliben at google.com> wrote:

> On Wed, Oct 1, 2014 at 3:12 PM, Alexander Kornienko <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?
>>
>
> FWIW, we ran into exactly the same need, and developed a bunch of utility
> methods that use the lexer to grab the next token, find matching tokens
> after some location, etc. Having these available somewhere in Clang would
> be definitely useful.
>

It sounds like one could put them into the Lexer (the Lexer already has
support for figuring out the right source ranges across macros, which is
related if one wants to do it right).

I think the big problem is that most code people write here covers the
99.9% case for their current problem. I'd expect covering this 100% in
general will be loads of code.


>
> Eli
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141002/2b4bbff3/attachment.html>


More information about the cfe-commits mailing list