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

[via cfe-dev]

I’m not sure of the exact list.

At least DeclStmt includes the semicolon:

 <https://github.com/llvm/llvm-project/blob/master/clang/lib/Parse/ParseDecl.cpp#L1801> https://github.com/llvm/llvm-project/blob/master/clang/lib/Parse/ParseDecl.cpp#L1801

 

But this does not matter that much. If tracking those Semicolons is too much, then it probably does

not matter much whether all Stmt behave the same or not as long as there is a way to get a location

with semicolon for those that need it.

I would try to add a comment to Stmt.getEndLoc to describe this as it’s at least surprising otherwise.

 

Alexander

 

 

Von: rjmccall at apple.com <rjmccall at apple.com> 
Gesendet: Dienstag, 17. März 2020 06:11
An: alex at lanin.de
Cc: Clang Dev <cfe-dev at lists.llvm.org>
Betreff: Re: [cfe-dev] Extend Stmt with proper end location?

 

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/ac6059fb/attachment.html>