[objc-improvements] Warnings when compiling GNUStep

[Ziemowit Laski]

The objc-improvements-branch compiler can now successfully churn its
way through the GNUstep compile-all script, although it does produce
some new warning messages along the way, and I wanted to solicit your
opinion as to what (if anything) to do about it.

First and foremost, we have numerous instances of the following:

   GSObjCRuntime.m: In function `GSAutoreleasedBuffer':

   GSObjCRuntime.m:1497: warning: `Class' may not respond to 
`+methodForSelector:'
   GSObjCRuntime.m:1497: warning: (Messages without a matching method 
signature
   GSObjCRuntime.m:1497: warning: will be assumed to return `id' and 
accept
   GSObjCRuntime.m:1497: warning: `...' as arguments.)
   GSObjCRuntime.m:1497: warning: assignment from incompatible pointer 
type

(The "incompatible pointer type" warning is a direct consequence of not 
finding
a suitable method in the first place.)  There does exist an instance 
`-methodForSelector:'
in the 'NSObject' class (which probably gets used in this case), but 
since Objective-C
allows multiple root classes, the compiler cannot statically decide to 
focus on NSObject.
What should we do?  I see 3 choices:
   (1) Leave things as they are.  Users will be able to suppress the 
above warning by
       casting the receiver to the root class (in above case, '(NSObject 
*)').
   (2) Build a list of all plausible root classes (i.e., classes without 
superclasses),
       and consult all instance methods for those classes when 
dispatching messages to
       'Class'
   (3) Treat messages to 'Class' the same way we treat messages to 'id', 
i.e., consult
       all class and instance methods available.  This is what the 
compiler appears to
       have done until now (in its mercurial and buggy way).

Personally, I like types (and compiler's warnings about them) :-), so 
I'd advocate we stick
with (1), but we could also do (3).  I'd really, really hate to have to 
implement (2), however.
Not only is it extra work, but it will adversely affect compile time.

Then, we have things like

   GSCompatibility.m:696: warning: multiple methods named 
`-objectForKey:' found
   GSFileHandle.m:1245: warning: multiple methods named `-objectForKey:' 
found
   GSFileHandle.m:1294: warning: multiple methods named `-objectForKey:' 
found
   NSUserDefaults.m:791: warning: multiple methods named 
`-initWithPath:' found
     :

where we're sending messages to receivers of type 'id'.  In the 
majority of cases,
the compiler is absolutely right to complain, and the receiver should 
be cast to a more
specific type (and/or the corresponding method signatures should be 
cleaned up so that
they match up).  However, in a few cases we're dealing with the idiom

    [[ClassName alloc] init...]

in which case one _could_ make the argument that any method named 
'alloc' should be treated
specially by the compiler, i.e., as having a return type covariant with 
the receiver.  What
do you think?  If we don't teach the compiler about 'alloc', then it is 
perfectly within
its right to complain in this case also, unless we change foregoing to 
read

    [(ClassName *)[ClassName alloc] init...]

which, I must admit, does have a slighty redundant flavor to it. :-(  
Of course, the
slippery slope argument applies here (if we treat 'alloc' specially, 
then what about
'allocWithFoo:Bar:'?...)

Finally, we have

   GSXML.m:3765: warning: `GSXPathObject' may not respond to 
`+_newWithNativePointer:context:'
   NSDistantObject.m:110: warning: `GSDistantObjectPlaceHolder' may not 
respond to `+class'
   NSTimeZone.m:685: warning: `NSTimeZone' may not respond to 
`+arrayWithObject:'
     :

all of which do seem reasonable to me, but please double-check.

Other than that, things look pretty good!  Please take the 
objc-improvements-branch compiler for a
spin one more time.  I'd like to get this pushed into mainline 3.4 as 
soon as feasible, so that I
may embark on phase 2 of my project -- Objective-C++! :-)

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477