unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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: Wed, 28 Jul 2010 19:45:11 +0000	[thread overview]
Message-ID: <20100728194511.GD2999@muc.de> (raw)
In-Reply-To: <AANLkTinL9pYA-yg2kOvD_N0+jVX+=uJcoVbBCvQ_qN87@mail.gmail.com>

Hi, Juanma,

On Wed, Jul 28, 2010 at 07:56:32PM +0200, Juanma Barranquero wrote:
> > What use is this warning message?  How could it prompt a hacker to
> > improve his code?  (That's a genuine question, not a rhetorical one.)

> It's a warning about non-side-effects code whose result is discarded,
> so it obviously prompts the programmer to either check that it didn't
> make a mistake (like forgetting to assign the expression's result to a
> variable), or remove the code altogether if it is leftover code from a
> cut&paste or refactoring.

OK, thanks.

> > What do you mean by "generic" here?  Is the same trick performed on
> > symbols other than 'xemacs?

> The warning has *nothing* to do with the xemacs symbol. It would still
> be there if you did "(and (not (featurep 'cc-fix)) nil ...)". It just
> happens to be triggered, in this particular case, by the byte-compiler
> optimizing (featurep 'xemacs) to nil. So the warning is entirely
> generic.

I'm not any more doubting the correctness of the message; I'm doubting
its adequacy.  Without understanding that (featurep 'xemacs) has been
optimised to nil, it's impossible to understand the current message
(either of them).  I've spent a long, long time puzzling over this error
message.  If only there were a warning about 'xemacs, it would be plain
and obvious.

> > Does anybody actually care about "(featurep 'xemacs)" being optimised
> > away?

> IIRC, optimizing (featurep 'xemacs) => nil is done, *precisely*, to
> help compiling portable code.

Misunderstanding, sorry!  I'm all in favour of this optimisation being
done.  But I don't care about it, in the sense I don't want to have to
make sense of a confusing message about it.  Does anybody care about
it enough to want that message in this particular case?  Couldn't the
optimisation just be done quietly in the background, with no warning?
Or couldn't there be a warning like

    "`(featurep 'xemacs)' has been translated to nil"

?

> Because you can have

>  (if (featurep 'xemacs)
>      ;; lots of code which would throw warnings or errors on Emacs
>      ;; because of incompatible parameter profiles and such
>    ;; else
>    ;; code for emacs

> and compile it without getting warnings of errors in code that will
> never be executed on Emacs anyway.

OK, I can see that.

>     Juanma

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2010-07-28 19:45 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100728194511.GD2999@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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).