[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

[Fariborz Jahanian]

On Feb 23, 2009, at 6:29 AM, steve naroff wrote:

>
> 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).

Now  is a good time to clean up the unintended features of objective-c  
in clang. Since gcc has supported
this feature for many years, some one might have used it (accidentally  
or not). We can do one or both of the following:

- Send this to a wider audience and see if they see a real use for  
them, then we can remove the warning, if they said yes.

- If no clear consensus is reached, we leave the warning in (as it is  
done now) and see if any project hits it. If not, then we can remove the
   feature (and change warning to error) at a later date.

- fariborz

>
>
> 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
>