Subject: bug#78716: 31.0.50; no byte compiler warnings for ignored side-effect-free function calls

From: Stefan Monnier <[email-masked]>
Date: Mon, 30 Jun 2025 15:33:37 -0400

>>> I suspect we'd need two ways: one which suppresses the warning
>>> recursively (lexical scope, of course, not dynamic), for all
>>> sub^n-arguments, and one which suppresses it only for one function call.
>> Could be.  The "all sub arguments" case is easy to fix (but I'm not
>> sure we'd ever need/want it; examples welcome), it's the other one
>> that's more interesting.
> I was thinking about pcase, cl-loop, and the cconv code; I expected all
> three to generate huge and complicated expressions which it might not be
> feasible to mix (maybe-ignore ...) calls into.

But if you silence all the warnings in the subtree, then it will also
silence unrelated warnings in the branches of the `pcase` which we don't want.

>>>> It's not completely trivial because we can't just wrap them like (FOO
>>>> (not (beep))) since the annotation should apply to the `not` operation
>>>> but not to its argument (the `beep` operation).
>>> I'm not sure I understand; the beep operation has no parameters, and
>>> wouldn't ignore its parameter if it had one.
>> The `beep` operation is the parameter to `not`.
> But it doesn't generate a warning, so how does the annotation apply to
> it?

When the argument is literally `(beep)` you're right, but I used it only
to indicate the position of the thing to which it could incorrectly apply.
Think of `(not (progn (< 0 x) (< x 10)))`

        Stefan