bug#81493: 30.2; Incorrect byte-compiler warning about unused value

[Sorry, Michael; I neglected to Reply All, so sending again.]

Hi Michael,

> Michael Heerdegen <[email protected]> writes:
> 
> > Note the compiler generates warnings for the expanded code - and above
> > the warning is (only) about the first `format' call.  You can interpret
> > it as a warning about a partially poorly written macro.
> 
> I have investigated some background for you.  Only few sexps would
> generate the same warning in this case:
> 
> The crucial properties of the `format' form here are "side effect free"
> and that it fulfills `byte-compile-trueconstp'.  The latter means that
> the byte compiler indeed has a test for forms that are guaranteed to
> eval to a non-nil value (tested by `byte-optimize-if').
> 
> So the warning is adequate and helpful IMO.  Maybe it could be more
> precise to be helpful - OTOH I don't think the wording of the warning
> would have helped Drew.

Thanks for looking into this!  I follow what you say about the
macro's use of its SINGULAR argument: `(when ,singular ...)',
including the fact that, in this particular case, the value of
SINGULAR is always a string, never nil.  That's not guaranteed
in general; but it's true in this case.

And I think I understand what you say about the byte-compiler
optimizing away `(when TRUE ...)' to just `...' for this use
of the macro.  It makes sense for the compiler to perform that
(minor) optimization.

But it doesn't make sense from a user point of view, I think.

It's normal that the macro code should only call `message',
passing the value of SINGULAR (after formatting) to `concat',
when SINGULAR isn't nil (otherwise the result of `message'
would just emit `s' for format's `%s' instead of something
like `files').

So this is a case, I think, where the byte-compiler warning is
bound to confuse more than help - anyone, regardless of how
the warning might be worded.

To understand the warning you have to (a) understand what the
compiler did (removed an `when' test in that macro's code,
(b) why it did that, and that it was right/OK to do it (it
wasn't needed in this case), and (c) why its doing that makes
no difference to the behavior/logic.

IOW, the code shouldn't be changed - it's correct as is, and
it should do what it does.  And the compiler does what it can
and should do, for an optimization (very, very, VERY minor,
in this case).

But ideally there would be NO warning in this case, as it
doesn't help in any way.  It can only confuse, and waste a
user's time trying to figure out what's being "warned" about.

This is not what _warnings_ should be for, IMO.  Byte-compiler
warnings should be about code that's likely to be incorrect.

Maybe there's no easy way for the compiler to be able to tell
the difference in a case like this between code that's likely
to be incorrect or nonkosher and code that's not problematic.
But ideally it would, and ideally it wouldn't warn about
anything here.

Please let me know, if you think I'm missing something.

Again, I appreciate very much your helping me by figuring this
out.  I would never have spent the time needed to investigate
this as far as you did.  Thx.