[cfe-commits] r65244 - in /cfe/trunk: include/clang/AST/ASTContext.h include/clang/AST/Type.h lib/AST/ASTContext.cpp lib/AST/Type.cpp lib/Sema/SemaType.cpp test/SemaObjC/protocol-archane.m

[steve naroff]

On Feb 23, 2009, at 1:08 AM, Chris Lattner wrote:

>>>>>
>>>>> Will never be seen in user code. Needed to pass dejagnu testsuite.
>>>>
>>>> So... why do we care? Why not just keep this unsupported? Or at
>>>> least,
>>>> warn about it?
>>>>
>>>
>>> I'm in a conforming mood:-)
>>>
>>> Kidding aside, I'm fine with not supporting it. I'd really like to
>>> avoid gratuitous changes to the type system like this.
>>>
>>> I'd like Chris and Fariborz to weigh in before I revert any  
>>> changes...
>>
>> If you are confident that there is no real use for it, then let's
>> remove this change and
>> issue an error instead. I have seen a few dejagnu tests, but they
>> could just be test coverage.
>
> Can you guys explain why this is horrible to someone not very  
> familiar with ObjC?
>

 From a language perspective, it's not that horrible. Here is an  
example:

@interface NSObject
+ self;
+ alloc;
- init;
@end

@protocol P
+ classM;
- instanceM;
@end

@interface C : NSObject <P>
@end

void func()
{
   id <P> anyInstanceThatRespondsToP = [[C alloc] init];
   // The GCC extension we are talking about allows you to express the  
following...
   Class <P> anyClassThatRespondsToP = [C self];

   [anyInstanceThatRespondsToP instanceM];
   [anyClassThatRespondsToP classM];
   // the following 2 should warn.
   [anyClassThatRespondsToP instanceM];
   [anyInstanceThatRespondsToP classM];
}

 From my perspective, this feature isn't that interesting/useful (and  
wasn't in the original language design).

Nevertheless, I decided to implement it (to be on the safe side).

> Unlike with C, I'm of the opinion that clang should clamp down on  
> some of the obscure ObjC GCC-isms that should never have be allowed  
> in the first place.  For better or worse, Clang's ObjC support is  
> what people will have to deal with in the future, and now is the  
> time to get it "right".
>

While the feature is obscure (and I don't believe used by any Apple  
software), it's not horrible conceptually.

> If we do reject this, we should emit a error that is 1) really good  
> and 2) explains that this is an intentional divergence from GCC, not  
> a bug in clang.
>

Since it's largely implemented now, I can't think of any compelling  
reason to remove it.

We can talk later,

snaroff

> -Chris