[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 12:30 PM, Fariborz Jahanian wrote:

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

Agreed.

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

Chris and I just spoke about this. He gave me the thumbs up on  
removing the feature (and adding an error).

Another idiom I'm going to remove is casting "super" (found in the  
same dejagnu test case).

I'm fairly confident no one will care. If they do, they can file a bug  
report.

snaroff

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