Re: PATCH: Selector warning

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

> >> +                 break;
> >> +               }
> >> +           }
> >> +         if (!found)
> >> +           {
> >> +             /* Adjust line number for warning message.  */
> >> +             int save_lineno = lineno;
> >> +             if (flag_next_runtime && TREE_PURPOSE(chain))
> >
> > I didn't try it out - just read the code - but an obvious questions 
> > pops
> > up here - why this instruction is only for the next runtime ?
> 
> Because, gnu runtime uses TREE_PURPOSE (chain) for different use. I did not exactly
> found a way to get correct line number for gnu runtime. May be you can provide me
> some  help.

What about checking for the selector when @selector() is actually found ?

In build_selector_expr() I mean.  Then you just use a warning() and to me
it makes so much more sense.  Of course to avoid the warning, the
declaration of the method must be before the @selector ... fair enough -
that is what I *would* expect - it is consistent with the checks done on
method calls etc where declaring the method after it's called still
generates the warning.  No big deal really, the #include and @interfaces
are normally before the @implementations and the code.

There would be another benefit - it would also makes sure if the compiler
hits that line, it generates the warning.  With your patch (I think, by
just looking at it quickly) an error before the final objc generation
would instead prevent the warning from being issued.

And I would hate it if it means when you start fixing warnings and errors
from line 1 forward, and when you get to the end and finally the stuff
compiles, new warnings start appearing from lines you thought were now
safe! :-)