bug#6740: Spurious byte compiler warnings

[Alan Mackenzie <acm@muc.de>]

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