This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Enhancing ObjC message lookup in the presence of protocols


Ziemowit Laski wrote:

> Your patch did more than that, I think, but overall you do raise a good
> point.  Either we should handle forward-declared protocols as you 
> suggest,
> or else I should drop the second part of my proposal.  At any rate,
> let's defer this to the next patch, and separate it from adding
> 'Class <Proto>' to the compiler in the first place.
> 

Well if you follow that thought through just a tad more then you'd
return to the original functionality I posted...

We don't artificially constrain marking forward declared protocols, but
mark all protocols adopted by root classes.  And insure the class hash
is filled with the corresponding methods.  Then we also insure this is
done for inherited protocols of root protocols.  So now we have the
"protocols adopted by root classes" marked, and we can use that
information during method lookup, do constrain the 'Class <Proto>'
lookup only to those marked protocols.  And now we're not only
potentially a tad bit faster but also more correct in the sense that we
reduce the potential of finding bogus cases of conflicting protocols!
It's really not that big of step and makes the whole search consistent.

> 
>> PS: Will you also send a mail concerning the semantic changes to 
>> objc_comptypes that your implementation has introduced? I do agree 
>> with some of them, but I don't think that they should be part of
>> this patch.
> 
> 
> Which ones do you mean?  I did notice that objc_comptypes is buggy in
> some cases (marked as FIXMEs in class-protocol-1.m), but I resisted
> mission creep in that case, since these bugs can be fixed as part of
> a future objc_comptypes rewrite.
> 

Actually I'm only concerned about:

(diff between my version and your version of class-protocol-1.m):
   { /* Class <protocol>, id */
-    obj == clsP1;
-    clsP1 == obj;
+    obj == clsP1; /* { dg-warning "lacks a cast" } */
+    clsP1 == obj; /* { dg-warning "lacks a cast" } */

   { /* Class <protocol>, id */
-    obj = clsP1;
-    clsP1 = obj;
+    obj = clsP1; /* { dg-warning "incompatible" } */
+    clsP1 = obj; /* { dg-warning "incompatible" } */

As I believe an unadorned 'id' should always be legal
(from comp-types-1.m):
  /* Assigning to an 'id' variable should never
     generate a warning.  */
  obj = obj_p;  /* Ok  */
  obj = obj_c;  /* Ok  */
  obj = obj_cp; /* Ok  */
  obj = obj_C;  /* Ok  */

...
  /* Any comparison involving an 'id' must be without warnings.  */
  if (obj == obj_p) ;  /* Ok  */ /*Bogus warning here in 2.95.4*/
  if (obj_p == obj) ;  /* Ok  */
  if (obj == obj_c) ;  /* Ok  */
  if (obj_c == obj) ;  /* Ok  */
  if (obj == obj_cp) ; /* Ok  */
  if (obj_cp == obj) ; /* Ok  */
  if (obj == obj_C) ;  /* Ok  */
  if (obj_C == obj) ;  /* Ok  */


> Aside from this, do you see any other problems with my current patch?

Other than the objc_comptypes issue I just mentioned (and that I
personally consider the 'Class <protocol>' support incomplete without
the infamous "root protocol" handling described above) I have found none
worth mentioning. :-).

Cheers,
David


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]