GNU bug report logs - #6740
Spurious byte compiler warnings

Previous Next

Full log

Message #23 received at 6740 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Dan Nicolaescu <dann <at> gnu.org>, 6740 <at> debbugs.gnu.org
Subject: Re: bug#6740: Spurious byte compiler warnings
Date: Wed, 28 Jul 2010 19:56:32 +0200

> But
> this discussion is most emphatically NOT about compiled code.  It's about
> the process of compiling sources.

Warnings do not affect compatibility, so no problem there (though I
admit they are ugly).

> 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.

> 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.

> Surely it is a bug that "(featurep 'cc-fix)" appears in the message
> rather than "(featurep 'xemacs)".  This situation is not about 'cc-fix,
> it's about 'xemacs.

Absolutely no, as shown above. At the point the byte-compiler throws
the warning, it does not know (I think) where the relevant nil came
from. It is rightly complaining that (featurep 'cc-fix) does nothing
and returns a value that goes unused. It would be possible to store
the original code before optimization and pass it to the warning
generation code, but it is likely not worth it.

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

IIRC, optimizing (featurep 'xemacs) => nil is done, *precisely*, to
help compiling portable code. 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.

    Juanma

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.