[cfe-dev] Objective-C tidy up
snaroff at apple.com
Tue Jun 3 11:01:10 PDT 2008
On Jun 3, 2008, at 10:23 AM, David Chisnall wrote:
> On 3 Jun 2008, at 17:49, Chris Lattner wrote:
>> On Jun 3, 2008, at 4:39 AM, David Chisnall wrote:
>>> On 3 Jun 2008, at 07:33, Chris Lattner wrote:
>>>> Why should self and _cmd be ParmVarDecls? Shouldn't they be
>>> That's what I did to start with, but PredefinedExprs need special
>>> handling in codegen, while ParmVarDecls are automatically turned
>>> into loads of %var.addr. Since they are parameters, and since it
>>> simplifies the rest of the implementation, it seemed like a
>>> ParmVarDecl would be the right thing to choose.
>> ParmVarDecl is an artifact of common implementations, not the way the
>> language works. They are not parameters, as they obviously don't
>> location info etc.
> They are artefacts of both all existing implementations (GNU, Apple,
> and POC) and the language philosophy ('no magic'), and is something
> relied on by a lot of existing code. You can promote them to
> explicit parameters by requesting a pointer to the function
> implementing the method (something supported by both Brad Cox's
> original design and implementation, and by OpenStep) and calling
> this as a C function.
When Brad and I were developing ObjC @ PPI, we never considered having
multiple ABI's and runtime's.
Today, it's clearer that the mechanism for calling a C function (that
represents a method) is ABI dependent.
I don't see any reason why the front-end needs to commit to these
details (especially for _cmd, which I regret, since it's so uncommon).
> The fact that they have no source location is merely syntactic sugar
> - they are real parameters and Objective-C programmers expect to be
> able to treat them as such. Treating them as something special
> seems like an unnecessary layer of abstraction which reflects
> neither how they are used nor how they are implemented.
> This is in contrast to super, which is an alias for self with
> different semantics (i.e. sending a message to super sends a message
> where the destination class is resolved at compile time, not at
>>>> +++ include/clang/AST/DeclObjC.h (working copy)
>>>> @@ -91,7 +91,8 @@
>>>> // The following are only used for method definitions, null
>>>> // FIXME: space savings opportunity, consider a sub-class.
>>>> Stmt *Body;
>>>> - ParmVarDecl *SelfDecl;
>>>> + // Decls for implicit parameters
>>>> + llvm::SmallVector<ParmVarDecl *, 2> ImplicitParamInfo;
>>>> If there are always exactly two of these, just use:
>>>> ParmVarDecl *ImplicitParamInfo;
>>> There will be three for the Étoilé runtime. Someone expressed
>>> interest in porting Objective-C to the COLA runtime from the
>>> Viewpoints Research Institute as well, and this would have somewhere
>>> between one and four depending on how they did it.
>> Please use a fixed size array. That is cheaper than a
> I've made this change, and included the updated diff.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev