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

[Enea Zaffanella]

On 06/04/2013 11:36 PM, Richard Smith wrote:
> On Tue, Jun 4, 2013 at 3:15 AM, Enea Zaffanella <zaffanella at cs.unipr.it
> <mailto: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.

Correct, the proposal was in this direction.

> 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.

If we stick to treating the mode attribute as a Decl attribute, then 
having separate Type and TypeSourceInfo fields in a TypedefNameDecl node 
is probably the simplest solution. As a matter of fact, this also 
matches what is now happening for ValueDecl nodes: getTypeSourceInfo() 
and getType() will return the type information before and after the 
application of the attribute, respectively.

Regarding implementation:

 > (2) for a typedef, there is no mechanism for the underlying type to
 > differ from the type implied by the type source info.

A TypedefNameDecl node also inherits (from TypeDecl) a Type pointer field:

   /// TypeForDecl - This indicates the Type object that represents
   /// this TypeDecl.  It is a cache maintained by
   /// ASTContext::getTypedefType, ASTContext::getTagDeclType, and
   /// ASTContext::getTemplateTypeParmType, and TemplateTypeParmDecl.
   mutable const Type *TypeForDecl;

Therefore, an option (having no memory space overhead) would be to build 
a TypedefNameDecl node where:

   - the TypeSourceInfo field points to the underlying type as written
     (i.e., before the application of mode attribute);

   - the TypeForDecl node points to the "semantic" typedef type
     (i.e., after the application of mode)

Clearly, the implementation of
   QualType getUnderlyingType() const {
     return TInfo->getType();
   }
should be changed to query the TypeForDecl field, rather than the TInfo 
field.

Are there reasons preventing such an approach?

Enea.