[cfe-commits] r75314 - in /cfe/trunk: include/clang/AST/ include/clang/Analysis/PathSensitive/ lib/AST/ lib/Analysis/ lib/CodeGen/ lib/Frontend/ lib/Sema/ test/CodeGenObjC/ test/PCH/ test/SemaObjC/ test/SemaObjCXX/

[Fariborz Jahanian]

On Jul 13, 2009, at 2:09 PM, steve naroff wrote:

>
> On Jul 13, 2009, at 4:58 PM, Fariborz Jahanian wrote:
>
>>
>> On Jul 13, 2009, at 1:18 PM, Chris Lattner wrote:
>>
>>>>
>>>> Sure. How about isObjCBuiltinType() and isObjCBuiltinInterface()?
>>
>> IsObjCIdBuiltinType() and isObjCClassBuiltinType(). Somehow, names  
>> should convey what they are.
>>
>
> Chris was suggesting we have a predicate to test for both 'id' and  
> 'Class'...

I got confused because you suggested two names (I thought one for each).

>
>
>>>>
>>>> GCC warns...
>>>>
>>>> test/SemaObjC/comptypes-5.m:29: warning: assignment from distinct  
>>>> Objective-C type
>>>> test/SemaObjC/comptypes-5.m:30: warning: assignment from distinct  
>>>> Objective-C type
>>>>
>>>> I decided to allow it. Rationale: Both MyClass and MyOtherClass  
>>>> implement MyProtocol. Since the protocols "match", and you can  
>>>> assign any 'id' to an interface type (without warning), I decided  
>>>> to allow it. I'm happy to put back the warning if others feel  
>>>> strongly (Fariborz?).
>>>
>>> I'll let Fariborz make this call.
>>
>> We should probably put the warning back.  Lack of a warning looks  
>> like a clang bug.  For example, clang (and gcc)
>> both issue warning here:
>>
>> @protocol MyProtocol
>> @end
>>
>> @interface MyClass
>> @end
>>
>> int main()
>> {
>> id <MyProtocol> obj_id_p;
>> MyClass *obj_c_cat_p;
>>
>> obj_c_cat_p = obj_id_p;
>> return 0;
>> }
>>
>> % $CLANGCC good.m
>> good.m:12:15: warning: incompatible type assigning  
>> 'id<MyProtocol>', expected 'MyClass *'
>> obj_c_cat_p = obj_id_p;
>>
>> But if you add a category conforming to the protocol (as in the  
>> test), then warning disappears in clang. Categories do not
>> enhance or change the type so behavior should not change.
>>
>
> Formally, I see your point (i.e. categories don't actually modify  
> the type). Nevertheless, categories allow methods to be added to a  
> class (a semantic that the compiler is very aware of). Since both  
> categories and protocols are nothing more than "method containers",  
> it seems like the compiler should be silent it determines the  
> message can be sent. With dynamic typing and forwarding, all of this  
> is speculative anyway:-) Just to be clear...I don't feel very  
> strongly about this. I just think we should do what makes sense (and  
> is in the spirit of the language). In this instance, I don't think  
> GCC compatibility is a big issue...

I agree your rational makes sense. But, let's not change this  
behavior. Our users are unforgiving when we remove their favorite  
warnings :).

>
>
> My 2$,

My 2cents :).

- fariborz