Re: New warnings (hopefully) in gcc 3.4

[Alexander Malmberg]

Nicola Pero wrote:
> Thanks.  At a quick look through your output, the following stands out as
> not particularly convincing:
> 
> NSMenu.m: In function `-[NSMenu update]':
> 
> NSMenu.m:804: warning: multiple methods named `-validateMenuItem:' found
> ../Headers/AppKit/NSMenu.h:562: warning: could be using 
> `-(BOOL)validateMenuItem:(id <NSMenuItem>)menuItem'
> ../Headers/AppKit/NSMenu.h:567: warning: or 
> `-(BOOL)validateMenuItem:(NSMenuItem *)aMenuItem'
> NSMenu.m:804: warning: (Messages matching multiple method prototypes
> NSMenu.m:804: warning: will be assumed to return `id' and accept
> NSMenu.m:804: warning: `...' as arguments.)
> NSMenu.m:804: warning: assignment makes integer from pointer without a cast
> 
> It seems there are two method definitions, both taking an object argument,
> and returning a BOOL.
> 
> They differ in the details of the class/protocol declared for the object
> argument, which is only used to do compile time type-checking, but should
> not affect generated code.

In this case, yes.

> It's uncertain how type-checking is to be done for the object argument
> (and the compiler is right to complain in that respect), but it's obvious
> that the method call should be compiled as taking an object argument and
> returning a BOOL, since both declarations agree on that.

I disagree. From a compiler pov, we don't know that the receiver
responds to this method at all in this case. Instead, we gamble that if
all prototypes for the selector are identical, then the prototype for
this receiver will probably be the same (this is case d. in my list).
When the prototypes aren't identical (case c.), we're stuck with a bunch
of prototypes and a receiver not known to implement any of them. I'm not
really happy about trying to combine prototypes or picking one randomly
(they might all be wrong, for all we know).

Anyway, since we're basically just guessing anyway, I guess it's ok (but
ugly :) to try to guess in a way that breaks as little real code as
possible. It seems the choices for behavior are:

1. Warn and use fallback prototype (like my current patch).
2. Pick one randomly (like previous versions of gcc).
3. Try to merge the prototypes in some way.

Note that although old versions of gcc used 2., you can't see it in this
case due to an issue in prototype comparisons. When adding a new
prototype to the global list of prototypes, it checked for type
"compatibility", not equality, so if the prototypes came in a certain
order, one would be considered equal to the other and would not be added
to the list.

Anyway, if 1. isn't good enough, I'd prefer 3. to 2., so I propose the
following merge scheme:

For the return type and the type of each argument, all prototypes for
the selector are checked.

If the types in all prototypes are the same, that type is used.
Otherwise, if the types in all prototypes are all objects, 'id' is used.
Otherwise, we abort the merge and use the fallback prototype.

Thoughts?

This would apply when no prototypes were found for the receiver's type,
but multiple prototypes were found when searching all prototypes, ie.
case c. in my list. Case b. is different.)

[snip]
> Sorry to be picky, but since you're putting the things in order, it might
> be worth putting this one in order too :-)

Certainly, but first we have to agree on what order we want to put
things in. From a language purity pov, I quite liked 1. :-)

- Alexander Malmberg