bug#6740: Spurious byte compiler warnings

[Juanma Barranquero]

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