From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#6740: Spurious byte compiler warnings Date: Thu, 29 Jul 2010 20:24:20 +0000 Message-ID: <20100729202420.GB2459@muc.de> References: <20100727200619.GC2280@muc.de> <20100727212328.GD2280@muc.de> <20100728174933.GB2999@muc.de> <20100728194511.GD2999@muc.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1280436123 31623 80.91.229.12 (29 Jul 2010 20:42:03 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 29 Jul 2010 20:42:03 +0000 (UTC) Cc: Dan Nicolaescu , 6740@debbugs.gnu.org To: Juanma Barranquero Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 29 22:42:02 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OeZuW-0003In-Dq for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Jul 2010 22:42:01 +0200 Original-Received: from localhost ([127.0.0.1]:33674 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeZtx-0001wk-PL for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Jul 2010 16:40:25 -0400 Original-Received: from [140.186.70.92] (port=35663 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OeZrg-00009u-CL for bug-gnu-emacs@gnu.org; Thu, 29 Jul 2010 16:38:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OeZrP-0002Gx-10 for bug-gnu-emacs@gnu.org; Thu, 29 Jul 2010 16:37:50 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:39418) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OeZrO-0002Gt-TQ for bug-gnu-emacs@gnu.org; Thu, 29 Jul 2010 16:37:46 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1OeZTT-0006Me-Tf; Thu, 29 Jul 2010 16:13:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Jul 2010 20:13:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 6740 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 6740-submit@debbugs.gnu.org id=B6740.128043438324457 (code B ref 6740); Thu, 29 Jul 2010 20:13:03 +0000 Original-Received: (at 6740) by debbugs.gnu.org; 29 Jul 2010 20:13:03 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OeZTR-0006MQ-LH for submit@debbugs.gnu.org; Thu, 29 Jul 2010 16:13:01 -0400 Original-Received: from colin.muc.de ([193.149.48.1] helo=mail.muc.de) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OeZTO-0006MK-8e for 6740@debbugs.gnu.org; Thu, 29 Jul 2010 16:12:59 -0400 Original-Received: (qmail 9692 invoked by uid 3782); 29 Jul 2010 20:13:11 -0000 Original-Received: from acm.muc.de (pD9E530D8.dip.t-dialin.net [217.229.48.216]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Thu, 29 Jul 2010 22:13:09 +0200 Original-Received: (qmail 4002 invoked by uid 1000); 29 Jul 2010 20:24:20 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Thu, 29 Jul 2010 16:13:03 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:39060 Archived-At: Hi, Juanma, On Wed, Jul 28, 2010 at 09:54:04PM +0200, Juanma Barranquero wrote: > On Wed, Jul 28, 2010 at 21:45, Alan Mackenzie wrote: > > I'm doubting its adequacy.  Without understanding that (featurep > > 'xemacs) has been optimised to nil, it's impossible to understand the > > current message > I think the message is a good hint that something is being statically > determined to be nil inside an `and'. No, sorry it isn't. It's a good hint that there's a bug in the byte compiler, the tentative conclusion I came to after trying various things. If it were such a good hint, I wouldn't have spent several hours of bafflement trying to figure out what was wrong. Or is it just me who's uniquely stupid? Is there anybody here listening in who's seen this message and immediately understood it? Abstractly seen, the warning did not relate to my source code; it related to an internal, transformed, different piece of source created by the compiler. I think warning messages should always be wrt the original code. > > If only there were a warning about 'xemacs, it would be plain and > > obvious. > But, as I've explained, there cannot (easily) be a warning about > `xemacs'; it would have to be about any code that statically evaluates > to nil in such a context. No. It would be about code which the _compiler_ had transformed to a static nil. The cause of my confusion was that silent change to 'xemacs. There are surely not too many situations where the compiler does this, are there? > I'm not sure how clean that would be to implement, and anyway no one > has been bothered enough to try it. :-) I know nothing of the byte compiler, but maybe I'll give it a go sometime. > > Does anybody care about it enough to want that message in this > > particular case? > Yes. You don't know whether a warning is relevant or not unless you > get it. In *this* particular case, all you need to quiet the > byte-compiler is > @@ -1,5 +1,5 @@ > (eval-when-compile > - (if (and (not (featurep 'cc-fix)) > - (featurep 'xemacs) > + (if (and (featurep 'xemacs) > + (not (featurep 'cc-fix)) > (progn > (require 'font-lock) Yes; I've already made that change, thanks! But what is the process by which I'm meant to come to sufficient understanding to be able figure this out? > > Couldn't the optimisation just be done quietly in the background, > > with no warning? > Why? The optimization is detecting something suspicious, and acting > accordingly. There's nothing suspicious about having (featurep 'xemacs) in the middle of an `and' form. I agree there would be something suspicious about having a bare `nil' there. Can't the compiler figure out the difference between these two cases somehow? > > Or couldn't there be a warning like > >    "`(featurep 'xemacs)' has been translated to nil" > ???? > That's worse that what you're complaining now; every use of (featurep > 'xemacs) in the sources would produce warnings! Oh, all right then. Can I ask you to come up with some form of warning which, several years ago, would have saved me all these hours of frustration? >     Juanma -- Alan Mackenzie (Nuremberg, Germany).