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

[Enea Zaffanella]

Ping.

Attached a slightly reviewed patch (only changes are in test cases, 
where c++11 syntax has been moved into more appropriate place and 
suitably quoted when checking it).

OK to commit?

Enea.

On 06/06/2013 11:44 AM, Enea Zaffanella wrote:
> 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.
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

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