Re: Looking for Objective-C team members to answer a protocol question

[Nicola Pero <nicola at brainstorm dot co dot uk>]

Hi,

I think this is a (pretty serious) bug in the compiler - the compiler is
ignoring casts between 'id', 'id<Protocol>' (and between 'id<Protocol1>
and id<Protocol2>').

Likely someone changed the C casting code without realizing that it would
impact ObjC ... and we didn't have any testcase for ObjC casts to catch
them when they did :-)

I already inserted the bug when casting an 'id<Protocol>' into an 'id', or
a 'id<Protocol1>' into a 'id<Protocol2>' in the GNATS database as 7808.

Could you please insert a bug report for casting 'id' into 'id<Protocol>'
into the GCC GNATS database ?

Specifically, I had a very quick look at this problem some days ago, and
if I remember properly what happens is that in the function build_c_cast()
inside gcc/c-typeck.c, the case if (type == TYPE_MAIN_VARIANT (TREE_TYPE
(value))) is used when the type of the variable before the cast is 'id'
(optionally with a Protocol), and the type we want to cast to is 'id'
again (optionally with a Protocol); that code detects that the
'TYPE_MAIN_VARIANT' is the same, and it ignores (or definitely does not
perform) the cast.  I suppose we might want to add in that 'if' case a
check that we are casting from/to an ObjC id, and then perform the cast if
needed.  Maybe call an ObjC specific function to do the check and cast ?
(similar to 'if (flag_objc) objc_comptypes (type, rhstype, 0);' used in
convert_for_assignment() when the TYPE_MAIN_VARIANTs of type and rhstype
are the same).

I don't have time to look at fixing it now, but I'd definitely like (since
it would allow me to play and learn a bit about C/ObjC types and casts in
the compiler :-), I'd probably have a serious look at it tonight.

Thanks for reporting the problem!  It's definitely useful.

> I have a pretty specific question about a change in the way the 
> Objective-C compiler checks protocols and casts of objects in 3.1 and 
> 3.2.  I have tried to find an explanation for this in the gcc source 
> code (couldn't) and don't find email addresses for the Objective-C team 
> members in the cvs. I've asked in a couple of usenet groups, but get no 
> answer.
> 
> So I'm asking here, hoping to find them or people who know them.
> 
> 
> The Swarm libraries (www.swarm.org) compile with gcc-3.0, but with
> gcc-3.1/3.2, we get some new warnings about protocols.
> 
> We have plenty of places where we cast ids as (id <whatever_protocol>) 
> and when the thing we cast does not actually implement all the methods 
> in the protocol, then the compiler warns us about it.  In the 3.0 gcc, 
> we did not get warnings.  If we use the flag -Wno-error instead of 
> -Werror, then the build of Swarm libraries finishes and programs that 
> run with the libraries work.
> 
> 
> I can give you a couple of examples. Consider this method:
> 
> 
> - setProbe: (id <Probe>)theProbe
> {
>    myProbe = (id <MessageProbe>) theProbe;
> 
>    return self;
> }
> 
> The compiler warns that  "warning: object does not conform to the
> `MessageProbe' protocol".  It no longer trusts us to make the cast the 
> way we wnat it.  Its warning is correct, "theProbe" does not conform. 
> But we don't want the warning.  I'm not saying the compiler is 
> incorrect.  Clearly, the compiler knows only that "theProbe" conforms to 
> <Probe> and not the <MessageProbe>, so it warns us.
> 
> We have the compiler set to treat warnings as errors, so I'd like to
> understand why this wrinkle appears now and what might be done about it.
> 
> By trial and error, I've found a workaround is to cast twice!
> 
> 
> - setProbe: (id <Probe>)theProbe
> {
>    myProbe = (id <MessageProbe>) (void *) theProbe;
> 
>    return self;
> }
> 
> But I am encouraged/prodded by my colleagues to ask why gcc changed in 
> this way.
> 
> There are a few other difficulties with the newer gcc, but maybe if you
> explain this protocol problem to me, I can figure the other things out.
> 
> Incidentally, I find the new gcc finds some mistakes that the old one 
> simply ignored.  For example, In a couple of cases where a superclass 
> uses a method that is implemented only in subclasses, we now get a 
> warning that it can't find the method in the class.  We didn't get that 
> before and I think it is a righteous one!