From: Alan Mackenzie <acm@muc.de>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: Dan Nicolaescu <dann@gnu.org>, 6740@debbugs.gnu.org
Subject: bug#6740: Spurious byte compiler warnings
Date: Thu, 29 Jul 2010 20:24:20 +0000 [thread overview]
Message-ID: <20100729202420.GB2459@muc.de> (raw)
In-Reply-To: <AANLkTinPrue70-0fO0Z+S=594dok0CmzZfo5WKgf22xg@mail.gmail.com>
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 <acm@muc.de> 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).
next prev parent reply other threads:[~2010-07-29 20:24 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-27 20:06 bug#6740: Spurious byte compiler warnings Alan Mackenzie
2010-07-27 20:26 ` Dan Nicolaescu
2010-07-27 21:23 ` Alan Mackenzie
2010-07-27 22:57 ` Juanma Barranquero
2010-07-28 17:49 ` Alan Mackenzie
2010-07-28 17:56 ` Juanma Barranquero
2010-07-28 19:45 ` Alan Mackenzie
2010-07-28 19:54 ` Juanma Barranquero
2010-07-28 23:00 ` Dan Nicolaescu
2010-07-29 20:24 ` Alan Mackenzie [this message]
2010-07-29 20:36 ` Juanma Barranquero
2010-07-27 21:40 ` Stefan Monnier
2020-11-19 4:25 ` Stefan Kangas
2020-11-24 6:40 ` Lars Ingebrigtsen
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=20100729202420.GB2459@muc.de \
--to=acm@muc.de \
--cc=6740@debbugs.gnu.org \
--cc=dann@gnu.org \
--cc=lekktu@gmail.com \
/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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.