[cfe-commits] r60993 - in /cfe/trunk: include/clang/AST/DeclObjC.h lib/AST/DeclObjC.cpp lib/Sema/SemaDecl.cpp lib/Sema/SemaDeclObjC.cpp

[Douglas Gregor]

On Dec 15, 2008, at 9:59 AM, Fariborz Jahanian wrote:

>
> On Dec 15, 2008, at 8:43 AM, Douglas Gregor wrote:
>
>> On Dec 13, 2008, at 12:28 PM, Fariborz Jahanian wrote:
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> ====================================================================
>>> --- cfe/trunk/lib/AST/DeclObjC.cpp (original)
>>> +++ cfe/trunk/lib/AST/DeclObjC.cpp Sat Dec 13 14:28:25 2008
>>> @@ -338,6 +338,17 @@
>>> return 0;
>>> }
>>>
>>> +void ObjCInterfaceDecl::CollectObjCIvars(std::vector<FieldDecl*>  
>>> &Fields) {
>>> +  ObjCInterfaceDecl *SuperClass = getSuperClass();
>>> +  if (SuperClass)
>>> +    SuperClass->CollectObjCIvars(Fields);
>>> +  for (ObjCInterfaceDecl::ivar_iterator I = ivar_begin(),
>>> +       E = ivar_end(); I != E; ++I) {
>>> +    ObjCIvarDecl *IVDecl = (*I);
>>> +    Fields.push_back(cast<FieldDecl>(IVDecl));
>>> +  }
>>> +}
>>> +
>>
>> There's a nearly identical routine called CollectIvars in lib/Sema/ 
>> SemaDecl.cpp, except that it creates ObjCAtDefsFieldDecls rather  
>> than collecting FieldDecls. Is CollectObjCIvars meant to do the  
>> same thing? And, is it part of semantic analysis (handling @defs)  
>> such that it should live in Sema, or is it a core operation on  
>> Objective-C AST's (and therefore should live in the AST)?
>
> It is part of the ASTs and is needed by the clients (code gen) in  
> this  case. I am collecting FieldDecl.  CollectIvars is also  
> collecting the fields
> for $defs AST but of a different node kind. These two can probably  
> be consolidated into one. I will add a FIXME for consideration.

Thanks.

>
>>
>>
>>> = 
>>> = 
>>> = 
>>> = 
>>> = 
>>> = 
>>> = 
>>> = 
>>> = 
>>> = 
>>> ====================================================================
>>> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>>> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Sat Dec 13 14:28:25 2008
>>> @@ -3075,8 +3075,10 @@
>>>     Consumer.HandleTagDeclDefinition(Record);
>>> } else {
>>>   ObjCIvarDecl **ClsFields = reinterpret_cast<ObjCIvarDecl**> 
>>> (&RecFields[0]);
>>> -    if (ObjCInterfaceDecl *ID = dyn_cast<ObjCInterfaceDecl> 
>>> (EnclosingDecl))
>>> +    if (ObjCInterfaceDecl *ID = dyn_cast<ObjCInterfaceDecl> 
>>> (EnclosingDecl)) {
>>>     ID->addInstanceVariablesToClass(ClsFields, RecFields.size(),  
>>> RBrac);
>>> +      ID->addLayoutToClass(Context);
>>> +    }
>>>   else if (ObjCImplementationDecl *IMPDecl =
>>>              dyn_cast<ObjCImplementationDecl>(EnclosingDecl)) {
>>>     assert(IMPDecl && "ActOnFields - missing  
>>> ObjCImplementationDecl");
>>
>> Will we need to have the RecordDecl layout for most or all  
>> Objective-C interfaces? If most programs only need the layout for a  
>> small number of interfaces, it might be beneficial to compute the  
>> layouts lazily (as we do with the layout of RecordDecls).
> Lay out is needed when a field is referenced. I will look at this  
> later when I am done with code gen.

Okay!

	- Doug