Re: [RFC] clang: 'unused-function' warning on static inline functions
From: Arnd Bergmann
Date: Wed Jun 07 2017 - 04:17:46 EST
On Tue, Jun 6, 2017 at 11:29 PM, Jens Axboe <axboe@xxxxxxxxx> wrote:
> On 06/06/2017 03:23 PM, Matthias Kaehlcke wrote:
>> El Tue, Jun 06, 2017 at 09:32:35AM -0700 Linus Torvalds ha dit:
>>
>>> On Tue, Jun 6, 2017 at 4:16 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>>>
>>>> Those should all be fairly easy to address, I'd vote for leaving the
>>>> warning enabled
>>>> in clang, and possibly asking the gcc maintainers to add a similar feature for
>>>> warning about it.
>>>
>>> Hell no. That warning is pointless shit.
>>
>> I tend to disagree, the warning is useful to detect truly unused
>> static inline functions, which should be removed, rather than be
>> carried around/maintained for often long periods of time.
>
> One example is the patch sent for CFQ, which has macros for define
> functions for setting/clearing bits on the queue:
>
> #define CFQ_CFQQ_FNS(name)
>
> for one bit, we never clear the bit after we set it, we only set it and
> later test for it. Hence the clear variant of that function is unused.
>
> Now I get a warning. The fix to that would be to define a new variant of
> CFQ_CFQQ_FNS() that only declares the exact one I need for the version
> that is never cleared.
>
> Or the fix is to just ignore the bogus warning on an unused inline. I
> greatly prefer the latter.
>
> The counter example is this one:
>
> http://git.kernel.dk/cgit/linux-block/commit/?id=03ea8ad78cfb2910862c8dfcd2a627fc04097db2
>
> where it is truly just dead junk. I'd rather just leave the dead junk
> than have pointless warnings, if I have to choose one of the two
> outcomes.
This is a relatively rare case, with an inline function defined by a macro, and
I sent a patch for a similar one in 1f318a8bafcf ("modules: mark
__inittest/__exittest
as __maybe_unused"). I think this is a case where the __maybe_unused
annotation is reasonable, though for the other instances of unused inline
functions in .c files, there is often a better way: typically the only caller
of a function is inside of an #ifdef and moving the inline function definition
into the same #ifdef block makes it clearer what is going on.
Arnd