GNU bug report logs - #78716
31.0.50; no byte compiler warnings for ignored side-effect-free function calls

Previous Next

Full log

Message #23 received at 78716 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 78716 <at> debbugs.gnu.org
Subject: Re: bug#78716: 31.0.50; no byte compiler warnings for ignored
 side-effect-free function calls
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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.