From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Nonsensical byte compiler warning. Date: 4 Apr 2007 22:08:55 +0200 Message-ID: <20070404212752.GA2717@muc.de> References: <85ps6okoe5.fsf@lola.goethe.zz> <87lkhcj791.fsf@stupidchicken.com> <87tzvwvj6c.fsf@gmx.at> <861wj04qcq.fsf@lola.quinscape.zz> <873b3gpn4u.fsf@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1175717354 16847 80.91.229.12 (4 Apr 2007 20:09:14 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2007 20:09:14 +0000 (UTC) Cc: Chong Yidong , rms@gnu.org, emacs-devel@gnu.org To: Markus Triska Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Apr 04 22:09:08 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HZBn1-00056D-1Z for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2007 22:09:07 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HZBqI-0007CP-TZ for ged-emacs-devel@m.gmane.org; Wed, 04 Apr 2007 16:12:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HZBqF-0007AV-V1 for emacs-devel@gnu.org; Wed, 04 Apr 2007 16:12:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HZBqC-00076O-9L for emacs-devel@gnu.org; Wed, 04 Apr 2007 16:12:26 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HZBqC-00076L-4j for emacs-devel@gnu.org; Wed, 04 Apr 2007 16:12:24 -0400 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1HZBmt-00053c-0j for emacs-devel@gnu.org; Wed, 04 Apr 2007 16:08:59 -0400 Original-Received: (qmail 75720 invoked by uid 3782); 4 Apr 2007 20:08:55 -0000 Original-Received: from acm.muc.de (p54A3E5C7.dip.t-dialin.net [84.163.229.199]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Wed, 04 Apr 2007 22:08:52 +0200 Original-Received: (qmail 3877 invoked by uid 1000); 4 Apr 2007 21:27:52 -0000 Original-Date: Wed, 4 Apr 2007 22:27:52 +0100 Content-Disposition: inline In-Reply-To: <873b3gpn4u.fsf@gmx.at> User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-kernel: FreeBSD 4.6-4.9 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:69069 Archived-At: Hi, Markus! On Wed, Apr 04, 2007 at 10:19:45AM +0200, Markus Triska wrote: > David Kastrup writes: > > It points to c-end-of-defun, but the line number and described > > called function are nonsensical. > The line number is that of the first form of the function the > questionable code is in. That makes sense, since the problem is in > that function. It is *not* the call of char-before that's bogus. It's > that its return value isn't used in the caller, c-end-of-defun. Any > line of that function could contain the oversight. What line number > would in your view make more sense to report? As the current maintainer of cc-cmds.el, I haven't found this message at all helpful. Here is the actual entry from my log of 2006-04-15, when I first tried to crack the problem: But I did get "While compiling c-end-of-defun in file /home/acm/cc-mode-5.31.n/cc-cmds.el: ** `(char-after (1- (point)))' called for effect". Track this down: It's in c-end-of-defun. By commenting out bits of the function in a binary chop fashion, it's L1625, "(eq (char-before) ?\})". I can't make head or tail of this. FIXME!!! POSTPONED. It didn't occur to me at the time that char-after and char-before were the same function. > And yes, improving the optimiser to report `char-before' instead of > `char-after' would be nice. I doubt that it would help anyone who > can't find the problem with the current (quite good) message though. As the "victim" of the situation, I would have found "char-before" _exceptionally_ helpful. It might have urged me to look at the code more carefully, rather than dismissing the message as a byte-compiler bug. As I say, I don't find the current message helpful: In c-end-of-defun: cc-cmds.el:1612:4:Warning: value returned by `char-after' is not used Taking the message bit by bit: (i) "c-end-of-defun" _is_ helpful; (ii) "1612:4" is positively unhelpful - at that location is "(interactive "p")". Giving "1612:4" actively hinders debugging. (iii) "char-after" doesn't exist in the source of c-end-of-defun; (iv) The value returned by "char-before" _is_ used; it is explicitly compared with "?\}". I think this warning message is buggy. What it says ("value ... is not used") is manifestly false - that value _is_ used; what isn't used is a different value which is derived from that value. What would a better message look like? I would suggest this: In c-end-of-defun: cc-cmds.el:1626:4:Warning: value returned from form is not used. (where 1626 starts the `if' form, the most nested form for which the warning holds). Or perhaps even better: In c-end-of-defun: cc-cmds.el:1647:57:Warning: value returned from form is not used. Would it be easy to make this change to the byte compiler? -- Alan Mackenzie (Ittersbach, Germany).