[cfe-commits] r50262 - in /cfe/trunk: include/clang/AST/Attr.h include/clang/Parse/AttributeList.h lib/Parse/AttributeList.cpp lib/Sema/Sema.h lib/Sema/SemaDecl.cpp

[Christopher Lamb]

It sounds like deprecated is really only used to control how  
diagnostics are emitted, and don't necessarily change code  
generation, and possibly unused the same. In which case I'm not sure  
there's a need to put that information in the Type. It'd depend on  
how the diagnostics for those cases are generated.

I'd think that alignment might be something potentially worth putting  
in Type itself, though keeping that info on the side in the  
ASTContext would also be a viable approach. I'm not sure what the  
tradeoffs of these two approaches would be.

For the attributes specific to tagged types (packing, ms/gcc_struct,  
and transparent_union) you can get the TagDecl directly from the type  
using getDecl()!  So I don't think you'd need to go through at all  
the same process as what was needed for ASQualType to implement  
transparent_union.

Do you know where the type enforcement on function parameters is  
done? If you know where that is I think making the needed changes is  
at least straighforward. =)
--
Chris

On Apr 26, 2008, at 11:01 AM, Nuno Lopes wrote:

> Well, at least the unused and deprecated attrs could live with such  
> type attributes. aligned could probably go to the ASTContext and  
> maybe packed+ms_struct+gcc_struct as well. packed could also live  
> in RecordType.
> Well I know that implementing the transparent_union attribute is a  
> bit harder than those mentioned above, but I really need that  
> working in order to compile PHP :P
>
> Anyone else?
>
> Nuno
>
>
> ----- Original Message ----- From: "Christopher Lamb"  
> <christopher.lamb at gmail.com>
> To: "Nuno Lopes" <nunoplopes at sapo.pt>
> Cc: <cfe-commits at cs.uiuc.edu>
> Sent: Saturday, April 26, 2008 4:36 AM
> Subject: Re: [cfe-commits] r50262 - in /cfe/trunk: include/clang/ 
> AST/Attr.h include/clang/Parse/AttributeList.h lib/Parse/ 
> AttributeList.cpp lib/Sema/Sema.h lib/Sema/SemaDecl.cpp
>
>
>> Nuno,
>>
>> Handling extra type attributes can be a bit complicated given that
>> the type system and type conversion are core operations at the heart
>> of the front-end. To implement address space qualified types has
>> required adding a new wrapper type (ASQualType) and supporting this
>> type throughout clang.
>>
>> It sounds like your new type attribute may be more narrowly
>> applicable to RecordTypes, but I don't think what you want can be
>> solved as easily as putting the Decl's type attributes on the Type
>> object itself. You can take a look at where ASQualType has been
>> introduced to see how essentially adding a single attribute (address
>> space) for a type, not only involves adding storage for that
>> attribute in the type system, but how it must be handled robustly
>> throughout the type modifications that happen in the front-end.
>>
>> Thinking about adding an extra field for Record types, or a wrapper
>> object for record types, are two ways of getting the information
>> through to code gen. It would also be informative to see where in the
>> code Record types are modified so that you could make a decision
>> about how hard it will be to propagate the information through.
>>
>> In all, adding such an attribute is not a quick task. I could never
>> have done the ASQualType stuff in GCC, so I think there is hope. Good
>> luck!
>> --
>> Chris
>>
>> On Apr 25, 2008, at 2:54 AM, Nuno Lopes wrote:
>>
>>> Hi,
>>>
>>> I was trying to implement the transparent_union type attribute, but
>>> I think
>>> we need some additional API to handle it. I think we should add the
>>> attribute API as found in Decl to Type (i.e. addAttr(), getAttrs
>>> (), ...).
>>> This could be used to implement this attribute and all the others  
>>> type
>>> attributes
>>> (http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Type-Attributes.html).
>>> Alternatively we could just add an ad-hoc field to the RecordType
>>> struct to
>>> record if it's a transparent union or not, which also makes sense.
>>>
>>> Please give me some feedback.
>>>
>>> Thanks,
>>> Nuno
>>>
>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=50262&view=rev
>>>> Log:
>>>> initial support for recognizing __transparent_union__ attributes
>>>> comments on the ML will follow
>>>> =================================================================== 
>>>> ==
>>>> =========
>>>> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>>>> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Apr 25 04:32:00 2008
>>>> @@ -2419,6 +2422,29 @@
>>>>                             Idx.getZExtValue(),
>>>> FirstArg.getZExtValue()));
>>>> }
>>>>
>>>> +void Sema::HandleTransparentUnionAttribute(Decl *d, AttributeList
>>>> *rawAttr) {
>>>> +  // check the attribute arguments.
>>>> +  if (rawAttr->getNumArgs() != 0) {
>>>> +    Diag(rawAttr->getLoc(),
>>>> diag::err_attribute_wrong_number_arguments,
>>>> +         std::string("0"));
>>>> +    return;
>>>> +  }
>>>> +
>>>> +  TypeDecl *decl = dyn_cast<TypeDecl>(d);
>>>> +
>>>> +  if (!decl || !Context.getTypeDeclType(decl)->isUnionType()) {
>>>> +    Diag(rawAttr->getLoc(), diag::warn_attribute_wrong_decl_type,
>>>> +         "transparent_union", "union");
>>>> +    return;
>>>> +  }
>>>> +
>>>> +  QualType QTy = Context.getTypeDeclType(decl);
>>>> +  const RecordType *Ty = QTy->getAsUnionType();
>>>> +
>>>> +// FIXME
>>>> +// Ty->addAttr(new TransparentUnionAttr());
>>>> +}
>>>> +
>>>
>>> _______________________________________________
>>> cfe-commits mailing list
>>> cfe-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>> --
>> Christopher Lamb
>

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20080426/66cd6018/attachment.html>