From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21647 invoked by alias); 6 Mar 2007 16:35:23 -0000 Received: (qmail 21637 invoked by uid 22791); 6 Mar 2007 16:35:22 -0000 X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,FORGED_RCVD_HELO,SARE_LWSHORTT X-Spam-Check-By: sourceware.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Mar 2007 16:35:16 +0000 Received: from dijkstra.wildebeest.org ([192.168.1.29]) by gnu.wildebeest.org with esmtp (Exim 4.43) id 1HOce2-00059I-FA; Tue, 06 Mar 2007 17:36:11 +0100 Subject: Re: frysk-imports/frysk/expunit ChangeLog Equals.j ... From: Mark Wielaard To: Andrew Cagney Cc: frysk@sourceware.org In-Reply-To: <45ED9168.6060505@redhat.com> References: <20070305135202.24295.qmail@sourceware.org> <45ED8846.4080901@redhat.com> <1173195413.4257.52.camel@dijkstra.wildebeest.org> <45ED9168.6060505@redhat.com> Content-Type: text/plain Date: Tue, 06 Mar 2007 16:35:00 -0000 Message-Id: <1173198912.4257.87.camel@dijkstra.wildebeest.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-1.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: -4.4 (----) X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q1/txt/msg00181.txt.bz2 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