On Aug 13, 2012, at 14:00 , João Matos <[email protected]> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
