[cfe-commits] r161703 - in /cfe/trunk: include/clang/AST/Stmt.h lib/AST/Stmt.cpp

[Jordan Rose]

On Aug 13, 2012, at 14:00 , João Matos <ripzonetriton at gmail.com> wrote:

> I agree with your reasoning from a semantic viewpoint, if we're not considering other use cases than code generation here. But the AST is being increasingly used in a lot more places than code generation, like for IDE support and refactoring, so it's a bit of tradeoff between syntax and semantic uses. In my experience it is much easier to consume this information for syntax purposes if it follows the syntax closely, instead of having to special case a lot of nodes that provide information in different ways.
> 
> I do have a question about this because I noticed lately a lot of nodes that do not provide locations for some syntactic elements. Should these be patched to provide them, or is it a goal for the AST tree nodes produced by the AST library to be kept as lightweight as possible and only suitable for semantic / code generation purposes? If so, should we provide another AST library that models nodes following syntax as close as possible?

If anything, I've always thought that it was an explicit goal of Clang's ASTs to indeed capture both the source representation and the semantic representation, per the standard. If just the former, we would have no ImplicitCastExprs; if just the latter, no ParenExprs. I think Richard and Abramo's posts show why these should feel like multiple statements on the syntactic side of things. I'm not sure what semantic benefit there is from having all the asm statements combined into one, even if it makes things easier on CodeGen. It seems like they're not really one statement until they reach IR.

To put up a straw man that is probably worse than anything else, what about an InlineAsmBlock that accrues all inline assembly statements and then gets implicitly closed when we reach a non-inline-asm or the end of a compound statement?

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120813/f3d43ef6/attachment.html>