[cfe-commits] r52051 - in /cfe/trunk/lib/AST: DeclObjC.cpp TranslationUnit.cpp

[Fariborz Jahanian]

On Jun 6, 2008, at 11:05 AM, Ted Kremenek wrote:

>
> On Jun 6, 2008, at 10:50 AM, Fariborz Jahanian wrote:
>
>>>>
>>>>
>>>> On Jun 6, 2008, at 10:21 AM, Ted Kremenek wrote:
>>>>
>>>>> Author: kremenek
>>>>> Date: Fri Jun  6 12:21:42 2008
>>>>> New Revision: 52051
>>>>>
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=52051&view=rev
>>>>> Log:
>>>>> Because of a lack of a clear ownership role between  
>>>>> ObjCInterfaceDecls and
>>>>> ObjCPropertyDecls, have TranslationUnit destroy  
>>>>> ObjCPropertyDecls. This is a
>>>>
>>>> I am not sure what you meant by ownership role?  
>>>> ObjCInterfaceDecls has the list of properties declared for the  
>>>> class. This is no different than ivars, methods, etc.
>>>>
>>>> - Fariborz
>>>
>>>
>>> From what I can tell, the PropertyDecls array in ObjCInterfaceDecl  
>>> contains both ObjCPropertyDecls created for the specific class as  
>>> well as the ObjCPropertyDecls in the parent class.  I may be  
>>> mistaken about this, but
>>
>> We are merging properties declared in class's protocol into those  
>> for current class. Look at:
>>
>> /// MergeOneProtocolPropertiesIntoClass - This routine goes thru  
>> the list
>> /// of properties declared in a protocol and adds them to the list
>> /// of properties for current class if it is not there already.
>> void
>> Sema::MergeOneProtocolPropertiesIntoClass(ObjCInterfaceDecl *IDecl,
>>                                           ObjCProtocolDecl *PDecl)
>>
>> - fariborz
>>
>
> Ah.  Thanks Fariborz.  Correct me if I am wrong, but this would also  
> imply a lack of a clear ownership model.  Different  
> ObjCInterfaceDecls may share the same protocols, and thus reference  
> the same ObjCPropertyDecls that were merged into their list of  
> properties.

Correct. But this is no different than the inherited protocols  
themselves. How do you establish ownership for them? Each protocol can  
be in multiple ObjCInterfaceDecl node, can it not?

>
> Just to be clear: when I mean a "lack of a clear ownership model", I  
> mean we cannot just iterate over the PropertyDecls array and destroy  
> the properties just declared for that specific ObjCInterfaceDecl.   
> Because both "local" properties and ones inherited from the  
> ObjCPropertyDecls are in this array, there is no simple way to  
> disambiguate who owns the ObjCPropertyDecl.

No you cannot. But it you can add the info. In ObjCPropertyDecl node  
to know where they come from, if you need to. And use the info. in the  
iterator you mentioned below.

- fariborz

>
> In the future, we probably just need a special iterator class for  
> iterating over the ObjCPropertyDecls associated with a class.  This  
> would walk over both the ObjCPropertyDecls associated with the  
> referenced ObjCProtocolDecls, but also the "local" properties  
> declared within @interface.  This will also provide a cleaner  
> mapping between the ASTs and the source code.
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20080606/05742c76/attachment.html>