All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
	Nicolas Schier <nicolas@fjasle.eu>,
	linux-kbuild@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH 1/4] kbuild: turn on -Wextra by default
Date: Tue, 9 Apr 2024 09:25:21 -0700	[thread overview]
Message-ID: <20240409162521.GB3219862@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20240404151713.3493098-2-arnd@kernel.org>

On Thu, Apr 04, 2024 at 05:16:54PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> The -Wextra option controls a number of different warnings that differ
> slightly by compiler version. Some are useful in general, others are
> better left at W=1 or higher. Based on earlier work, the ones that
> should be disabled by default are left for the higher warning levels
> already, and a lot of the useful ones have no remaining output when
> enabled.
> 
> Move the -Wextra option up into the set of default-enabled warnings
> and just rely on the individual ones getting disabled as needed.
> 
> The -Wunused warning was always grouped with this, so turn it on
> by default as well, except for the -Wunused-parameter warning that
> really has no value at all for the kernel since many interfaces
> have intentionally unused arguments.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

I have not done any LLVM builds with this change but if this is going to
be in -next for a little bit, we should be able to get any regressions
handled quickly.

I am in favor of more warnings but I am a little nervous this will make
compiler upgrades (or tracking their mainline) even more difficult. I do
not have a feeling for how often warnings are added to -Wall and -Wextra
so this may be unfounded but the kernel's -Werror use complicates this
in my opinion. I can engage with the clang folks to try and be given a
heads up when a warning is going to be added to -Wextra, it would be
good to have someone do something similar for GCC, so that those
upgrades do not cause something like this change to be rolled back.

It is easy enough to back out of this if necessary though, so:

Acked-by: Nathan Chancellor <nathan@kernel.org>

> ---
>  scripts/Makefile.extrawarn | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn
> index c5af566e911a..c247552c192c 100644
> --- a/scripts/Makefile.extrawarn
> +++ b/scripts/Makefile.extrawarn
> @@ -82,12 +82,14 @@ KBUILD_CFLAGS += $(call cc-option,-Werror=designated-init)
>  # Warn if there is an enum types mismatch
>  KBUILD_CFLAGS += $(call cc-option,-Wenum-conversion)
>  
> +KBUILD_CFLAGS += -Wextra
> +KBUILD_CFLAGS += -Wunused
> +
>  #
>  # W=1 - warnings which may be relevant and do not occur too often
>  #
>  ifneq ($(findstring 1, $(KBUILD_EXTRA_WARN)),)
>  
> -KBUILD_CFLAGS += -Wextra -Wunused -Wno-unused-parameter
>  KBUILD_CFLAGS += $(call cc-option, -Wrestrict)
>  KBUILD_CFLAGS += -Wmissing-format-attribute
>  KBUILD_CFLAGS += -Wold-style-definition
> @@ -190,6 +192,7 @@ else
>  
>  # The following turn off the warnings enabled by -Wextra
>  KBUILD_CFLAGS += -Wno-sign-compare
> +KBUILD_CFLAGS += -Wno-unused-parameter
>  
>  endif
>  
> -- 
> 2.39.2
> 

  reply	other threads:[~2024-04-09 16:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-04 15:16 [PATCH 0/4] Enable more warnings by default Arnd Bergmann
2024-04-04 15:16 ` [PATCH 1/4] kbuild: turn on -Wextra " Arnd Bergmann
2024-04-09 16:25   ` Nathan Chancellor [this message]
2024-04-09 18:42     ` Arnd Bergmann
2024-04-04 15:16 ` [PATCH 2/4] kbuild: remove redundant extra warning flags Arnd Bergmann
2024-04-04 15:16 ` [PATCH 3/4] kbuild: turn on -Wrestrict by default Arnd Bergmann
2024-04-04 15:16 ` [PATCH 4/4] kbuild: enable -Wformat-truncation on clang Arnd Bergmann
2024-04-08 22:00 ` [PATCH 0/4] Enable more warnings by default Justin Stitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240409162521.GB3219862@dev-arch.thelio-3990X \
    --to=nathan@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arnd@kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=nicolas@fjasle.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.