From: Mark Wielaard <mark@klomp.org>
To: Andrew Cagney <cagney@redhat.com>
Cc: frysk@sourceware.org
Subject: Re: frysk-imports/frysk/expunit ChangeLog Equals.j ...
Date: Tue, 06 Mar 2007 16:35:00 -0000 [thread overview]
Message-ID: <1173198912.4257.87.camel@dijkstra.wildebeest.org> (raw)
In-Reply-To: <45ED9168.6060505@redhat.com>
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
next prev parent reply other threads:[~2007-03-06 16:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20070305135202.24295.qmail@sourceware.org>
2007-03-06 15:27 ` Andrew Cagney
2007-03-06 15:37 ` Mark Wielaard
2007-03-06 16:06 ` Andrew Cagney
2007-03-06 16:35 ` Mark Wielaard [this message]
2007-03-06 17:15 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1173198912.4257.87.camel@dijkstra.wildebeest.org \
--to=mark@klomp.org \
--cc=cagney@redhat.com \
--cc=frysk@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).