From: Juanma Barranquero <lekktu@gmail.com>
To: Alan Mackenzie <acm@muc.de>
Cc: Dan Nicolaescu <dann@gnu.org>, 6740@debbugs.gnu.org
Subject: bug#6740: Spurious byte compiler warnings
Date: Thu, 29 Jul 2010 22:36:23 +0200 [thread overview]
Message-ID: <AANLkTik4xbU23rhOKqcunf3T+_k9-CygthVM3SzN191v@mail.gmail.com> (raw)
In-Reply-To: <20100729202420.GB2459@muc.de>
On Thu, Jul 29, 2010 at 22:24, Alan Mackenzie <acm@muc.de> wrote:
> 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.
No, of course not, because there's no bug (well, other than the
duplicate message).
The warning is obscure, yes. Warnings about optimized code often are.
I agree that it'd be good to have better warnings and error messages
(something like "optimization X has rendered code Y unused", perhaps).
IIRC, there's published research about good error messages in the face
of program transformations.
> 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?
It's not about being stupid, only about knowing a bit what the
bytecompiler does, or not. You didn't, and you're *right* that the
warning is difficult to interpret.
> Is there anybody here listening in who's seen this
> message and immediately understood it?
Well, I did, but I remembered the (featurep 'xemacs) optimization so I
had a head start.
> 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.
Agreed.
> 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?
Even if there aren't many, optimizations could be added later; for
example, to statically determine that (= 0 0) is t, or even that (and
(> x 0) (< x 0)) is nil.
> 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?
That's a good question.
> There's nothing suspicious about having (featurep 'xemacs) in the middle
> of an `and' form.
No, but the warning isn't about that. Is about unused side-effect-free code.
> 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?
Yes, it could. Again, no one has bothered to implement it, because
these kinds of problems aren't common (most warnings are relatively
understandable withouth delving into the bytecompiler sources).
> 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?
Not me. I understand what the bytecompiler is doing (at least, I think
I do) but I'll leave fixing it for the experts.
Juanma
next prev parent reply other threads:[~2010-07-29 20:36 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
2010-07-29 20:36 ` Juanma Barranquero [this message]
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=AANLkTik4xbU23rhOKqcunf3T+_k9-CygthVM3SzN191v@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=6740@debbugs.gnu.org \
--cc=acm@muc.de \
--cc=dann@gnu.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.
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.