GNU bug report logs -
#6740
Spurious byte compiler warnings
Previous Next
Full log
View this message in rfc822 format
On Wed, Jul 28, 2010 at 21:45, Alan Mackenzie <acm <at> 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'.
> (either of them).
Yes, that's a bug :-)
> If only there were a warning about 'xemacs, it would be plain
> and obvious.
But, as I've explained, there cannot (easily) be a waning about
`xemacs'; it would have to be about any code that statically evaluates
to nil in such a context. I'm not sure how clean that would be to
implement, and anyway no one has been bothered enough to try it.
> 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)
> Couldn't the
> optimisation just be done quietly in the background, with no warning?
Why? The optimization is detecting something suspicious, and acting
accordingly.
> 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!
Juanma
This bug report was last modified 4 years and 202 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.