[cfe-dev] Mode attribute not in clang AST.

Richard Smith richard at metafoo.co.uk
Tue Jun 4 14:36:15 PDT 2013


On Tue, Jun 4, 2013 at 3:15 AM, Enea Zaffanella <zaffanella at cs.unipr.it>wrote:

> I was wondering why the gnu "mode" attribute, even though being parsed by
> clang and affecting the AST construction, is not otherwise recorded in its
> own AST node:
>
> def Mode : Attr {
>   let Spellings = [GNU<"mode">, CXX11<"gnu", "mode">];
>   let Args = [IdentifierArgument<"Mode">];
>   let ASTNode = 0;
> }
>
> Other attributes having ASTNode = 0 are typically those corresponding to
> AttributedType nodes, but "mode" is not modeled as an AttributedType.
>
> Would it be OK to remove the line "let ASTNode = 0" above and modify
> Sema::handleModeAttr to actually build the node?


Just so I'm clear: I think you're suggesting modeling 'mode' as a Decl
attribute, and not as an AttributedType (or similar). That seems reasonable
given the semantics of the 'mode' attribute. However, there is an
interacting problem here: the 'mode' attribude currently causes us to
discard type source info for a typedef to which it is applied, because (1)
we have no type-level representation of the attribute, and (2) for a
typedef, there is no mechanism for the underlying type to differ from the
type implied by the type source info. There seem to be two natural
solutions to that problem: a type-level representation of the 'mode'
attribute (using AttributedType or similar), or allowing typedefs to have
separate type and type source info. I think it makes sense to have an idea
of how to solve both of these problems before attacking either of them,
since their solutions interact.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130604/0d19f413/attachment.html>


More information about the cfe-dev mailing list