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

From: Stefan Monnier <[email-masked]>
Date: Sat, 28 Jun 2025 18:26:06 -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.

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

> IIUC, you're saying that we need the non-recursive option above, but not
> the recursive one?

That's right.

> I'm not sure I agree,

Why?  We do want to `beep` here.  The only part that we should remove is
the silly `not` operation.

> but would that really be hard?

Don't know.

> We already have a recursive option which works, and the non-recursive
> option would be just like 'ignore'.

Maybe you're right, I simply don't know.

>>> 	(if (not m)
>>> 	    ;; Go to dependencies, and search there.
>>> 	    nil)
>>> 	m))))
>>>
>>> probably should generate a warning, because the if form seems completely
>>> mysterious to me.
>> At the same time: is it an actual problem?
> Mysterious code which no one can now determine the intention of?
> Sounds like a problem to me!

We have an endless supply of such code, tho, most of which doesn't have
the property of being "cosmetically silly".

>>> The second class of warnings should not be enabled by default, but maybe
>>> it can become an 'extra warning level which we run once in a while?
>> Adding a notion of "level" for warnings that aren't super-important
>> might make sense, yes.
> OTOH, wasn't that what elint was for?

Could be.  I don't know much about elint, other than that it never
seemed to do anything very useful when I tried it.

In any case, whether it's implement in the compiler or in a separate
package, the requirement remains to provide a way to silence the
false-positives.

>> I'd still welcome some way to silence those
>> warnings locally rather than via some global setting.
>
> (with-suppressed-warnings ((lexical . t))
> ... various incomplete defuns ...
> )

But if you use it within a macro around code provided by the caller, you
risk silencing real problems.  So, for the same reason we moved from
`with-no-warnings` to `with-suppressed-warnings`, I'd rather have
something that has a more local effect.

This said, maybe we want a general "single-level" version of
`with-suppressed-warnings` since I've already several times wanted a way
to suppress a particular kind of warning but only for the top-level of
an expression and not for all the sub-expressions it may hold.

I think such a ". t" option would be good for a "single-level"
warning suppressor since in most cases it's obvious which warning it
would apply to.

For `with-suppressed-warnings`, OTOH, I'm not sure I want to encourage
people to suppress all lexical warnings within all the subexpressions of
a form.

        Stefan