Re: [PATCH] maple_tree: Fix build failure with W=1 and LLVM=1

[Nathan Chancellor <nathan@kernel.org>]

On Fri, May 03, 2024 at 02:29:12PM +0100, Matthew Wilcox wrote:
> On Fri, May 03, 2024 at 09:01:06PM +0800, Kuan-Wei Chiu wrote:
> > On Fri, May 03, 2024 at 01:20:32PM +0100, Matthew Wilcox wrote:
> > > On Fri, May 03, 2024 at 05:50:27PM +0800, Kuan-Wei Chiu wrote:
> > > > When compiling library code using "make W=1 LLVM=1 lib/", clang
> > > > generated the following compilation errors:
> > > > 
> > > > lib/maple_tree.c:351:21: error: unused function 'mte_set_full' [-Werror,-Wunused-function]
> > > > static inline void *mte_set_full(const struct maple_enode *node)
> > > 
> > > Uh, clang is wrong to flag these as an error.  They're just not used
> > > yet.
> > 
> > I think it's because the kernel defaults to treating all compilation
> > warnings as errors. If you turn off the option to treat compilation
> > warnings as errors, they will be treated as warnings instead. Should I
> > update my commit message to change compilation errors to compilation
> > warnings?
> 
> just don't use W=1 and clang.

This patch has effectively been sent four times now:

https://lore.kernel.org/all/20220914101829.82000-1-jiapeng.chong@linux.alibaba.com/
https://lore.kernel.org/all/20230217084647.50471-1-jiapeng.chong@linux.alibaba.com/
https://lore.kernel.org/all/20230319132903.1702426-1-trix@redhat.com/
https://lore.kernel.org/all/20240503095027.747838-1-visitorckw@gmail.com/ (this change obviously)

Your first comment from the 2022 patch:

  They're not used now, but they will be in a release or two.

I think a few releases have passed since then :) I don't personally care
if there is a solution here or not, as I don't test with W=1 (there's
enough to do at W=0 :P), but maybe it is time for either __maybe_unused
(as that strikes at the heart of the issue) or at the very least a
comment saying "hey, these functions are currently unused but there are
plans for them to be used, so don't remove them", rather than just
saying the status quo?

Cheers,
Nathan