GNU bug report logs -
#78716
31.0.50; no byte compiler warnings for ignored side-effect-free function calls
Previous Next
Full log
View this message in rfc822 format
> 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
This bug report was last modified 43 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.