Hi Andrew,
On Tue, 2007-03-06 at 11:06 -0500, Andrew Cagney wrote:
I did a quick clean revert; methods such as group(...) were still
missing :-(.
Yes, I didn't put those back because I thought they weren't consistently
implemented (but see below). We could do with a little bit more API
review and documentation at times to prevent misinterpretation over
required functionality.
Can you post the warnings you're seeing so you/i can figure out what
really should be changed? If the warnings are significantly different
then there's the complicating problem - for the moment only you will be
seeing and fixing those problems. In the short term, it may be prudent
to scale back the warnings issued by the new compiler.
Yes, I just suggested the same in my Status mail. For now to build on
rawhide we should just use the disable-warnings patch that I attached to
this email: http://sourceware.org/ml/frysk/2007-q1/msg00173.html
And then we wait for this bug to get fixed (is already fixed upstream,
but needs a push into rawhide):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231020
before going over all the warning elimination again (and maybe select a
different set of warnings by default).
The new warnings that ecj gives are for unused method parameters. That
reflects the design of that API though. ecj seems to prefer abstract
methods in base classes over stubbed default implementations. I do
actually agree with ecj in this case which is why I rewrote them that
way (and left the group methods out since they weren't actually used in
the code). So ecj can be used to enforce a particular API design style,
but to do that we probably need to have a discussion about the preferred
styles first. As soon as the above bug is fixed, new packages are in
rawhide and more people have had a chance to play with the new warning
settings we should go over them and make a selection of the defaults we
actually want.
Cheers,
Mark