[cfe-dev] Objective-C tidy up

[David Chisnall]

On 6 Jun 2008, at 07:36, Chris Lattner wrote:

>
> On Jun 5, 2008, at 8:26 AM, David Chisnall wrote:
>
>> On 4 Jun 2008, at 18:11, Chris Lattner wrote:
>>
>>>> Any function in Objective-C can use self and _cmd as identifier
>>>> names.  Any occurrence of the 'this' token in a C++ program refers
>>>> to an instance of an object with a type defined by the context.
>>>
>>> Does 'super' in ObjC work the same way?
>>
>> Yes.  Objective-C is a pure superset of C, so anything that is valid
>> C is valid Objective-C.  Which means my current handling of super is
>> wrong...
>>
>> I'm not sure the best way to handle this, since super has very
>> specific semantics in Objective-C (it is only valid as the receiver
>> for messages) and so can't just have a phantom decl added.
>> Suggestions welcome...
>
> Ok.  I think we converged on this.  the parsing code is nearly right
> for super (please check in your fix) and modeling it as predefined
> expr is great.

I think super is right now.

>>>> So, the question is not what should occurrences of the self and  
>>>> _cmd
>>>> tokens be turned into (although that might be a separate question),
>>>> it's what the entries in the decl map should be populated with.  As
>>>> far as my code goes, this can be pretty much any sort of decl.  It
>>>> needs to have a type associated with it for Sema to be able to be
>>>> able to do type checking (for self, this is a pointer to an  
>>>> instance
>>>> of the current class, e.g. NSObject*, for _cmd it is SEL).  For
>>>> CodeGen, it needs to have a name.
>>>
>>> Gotcha.  What do you think of a new subclass of ValueDecl?
>>
>> Do we need a new subclass?  I'm not actually sure what this needs
>> that a ValueDecl doesn't provide, so we could possibly just use a
>> ValueDecl.
>
> If that works, please go for it.  Please add a big comment above te
> ValueDecl class indicating that ObjC uses it this way though.

ValueDecl's constructor is currently private, so I've added a public  
Create() method.  This seems to work.  I wasn't using anything  
specific to the param decl, so (after fixing a load of compiler  
complaints) it is working again.

>>> It would be really nice to lazily allocate these objects when they
>>> are
>>> first used.  This would allow us to avoid allocating the _cmd decl
>>> for
>>> almost every ObjC method, and avoid 'self' on many of them.
>>
>> That would be ideal.  I'm not sure where the best place to put it
>> would be.  Ideally I would want failed lookups in the decl map to
>> insert it, but I think a few places access the decl map.  One other
>> option would be to allocate the self decl on a per-class basis
>> (since it's the same for every method in a class - a pointer to an
>> instance of that class) and the _cmd once per module.  It would
>> probably easier to allocate them both once per class.
>
> Take a look at how name lookup is currently working and how builtins
> are lazily created, you should be able to do something similar.

This is fine for codegen.  Will other AST consumers object if implicit  
parameter decls aren't there if they are not referenced?

>> It is very rare to have a class which does not contain at least one
>> reference to self.  Most classes will override -init, and the common
>> pattern for this is to start the method with:
>>
>> if (nil == (self = [self init])) return nil;
>
> Sure, but we'd need to make one decl for self in *every method* that
> references it, not once per class.

Can we not have one decl object instance per class, but one decl map  
entry (pointing to this instance)?

>> References to _cmd are less common - they are generally only used
>> for message forwarding (which tends to only be done in a root class)
>> or for debugging.
>
> Sure.
>
>> [1] These should probably have a common superclass, since they are
>> almost identical - in fact an ObjCImplementationDecl could inherit
>> from ObjCCategoryImplDecl, since a class is effectively a category
>> which is allowed to declare instance variables.
>
> I think it would be great to unify some of this stuff.  There is a lot
> of awkward code in the objc front-end for groking this stuff that
> should be unified, but I haven't figured out how.  Suggestions
> welcome :)

I still have about 2000 lines of uncommitted diffs, but when my tree  
has sync'd up with trunk a bit better then I'll take a look at the  
front end a bit and see what can be unified.  There are a few other  
strange things there, such as the 'isArrow' property on ivar refs  
which, unless I am missing something important, can never be false.

David