On Tue, Jun 4, 2013 at 3:15 AM, Enea Zaffanella <span dir="ltr"><<a href="mailto:zaffanella@cs.unipr.it" target="_blank">zaffanella@cs.unipr.it</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
def Mode : Attr {<br>
  let Spellings = [GNU<"mode">, CXX11<"gnu", "mode">];<br>
  let Args = [IdentifierArgument<"Mode">];<br>
  let ASTNode = 0;<br>
}<br>
<br>
Other attributes having ASTNode = 0 are typically those corresponding to AttributedType nodes, but "mode" is not modeled as an AttributedType.<br>
<br>
Would it be OK to remove the line "let ASTNode = 0" above and modify Sema::handleModeAttr to actually build the node?</blockquote><div><br></div><div>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.</div>
</div>