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

[Enea Zaffanella]

On 06/04/2013 11:36 PM, Richard Smith wrote:
[...]
> 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.

Please find attached a patch for review.

The approach is to:
  - model mode attributes as declaration attributes;
  - separate type and type source info in TypedefNameDecl nodes:
    this only occurs when needed, i.e., when the decl node has
    been "moded" (no memory overhead in the common case);
  - in the "moded" case, the type source info is left untouched,
    but getUnderlyingType() will return the type after mode application,
    so that everything behaves as before.

The original type source info is used when pretty printing the 
TypedefNameDecl node (together with the mode attribute).
The patch adds a couple of tests for the pretty printer.


For the pretty printing of VarDecl nodes:

-  QualType T = 
D->getASTContext().getUnqualifiedObjCPointerType(D->getType());
-  if (ParmVarDecl *Parm = dyn_cast<ParmVarDecl>(D))
-    T = Parm->getOriginalType();
+  QualType T = D->getTypeSourceInfo()
+    ? D->getTypeSourceInfo()->getType()
+    : D->getASTContext().getUnqualifiedObjCPointerType(D->getType());
    T.print(Out, Policy, D->getName());

Doubt is the following: should we apply getUnqualifiedObjCPointerType 
even when considering the type source info case?

Enea.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ModeAttr.patch
Type: text/x-diff
Size: 7176 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130606/7ca18b78/attachment.patch>