git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sunshine <sunshine@sunshineco.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 7/6] CodingGuidelines: mention -Wunused-parameter and UNUSED
Date: Wed, 28 Aug 2024 15:53:53 -0400	[thread overview]
Message-ID: <CAPig+cSBPxtv50KknJVbucAa9RGxQxP66XHpjCjECWdSGPRHjw@mail.gmail.com> (raw)
In-Reply-To: <20240828144814.GB4020916@coredump.intra.peff.net>

On Wed, Aug 28, 2024 at 10:48 AM Jeff King <peff@peff.net> wrote:
> On Wed, Aug 28, 2024 at 01:56:13AM -0400, Eric Sunshine wrote:
> > What is the expectation regarding newcomers to the project or even
> > people who have not been following this topic and its cousins?
> > Documentation/CodingGuidelines recommends enabling DEVELOPER mode,
> > which is good, but this change means that such people may now be hit
> > with a compiler complaint which they don't necessarily know how to
> > deal with in the legitimate case #3 (described above). Should
> > CodingGuidelines be updated to mention "UNUSED" and the circumstances
> > under which it should be used?
>
> Yeah, I agree some guidance is in order. How about this on top? I didn't
> go into the decision tree of when you should remove the parameter versus
> using it versus annotating it. I think in general that the first two are
> pretty obvious when they are appropriate, and we just need to focus on
> the annotating option.
>
> -- >8 --
> Subject: [PATCH] CodingGuidelines: mention -Wunused-parameter and UNUSED
>
> Now that -Wunused-parameter is on by default for DEVELOPER=1 builds,
> people may trigger it, blocking their build. When it's a mistake for the
> parameter to exist, the path forward is obvious: remove it. But
> sometimes you need to suppress the warning, and the "UNUSED" mechanism
> for that is specific to our project, so people may not know about it.
>
> Let's put some advice in CodingGuidelines, including an example warning
> message. That should help people who grep for the warning text after
> seeing it from the compiler.

Makes sense.

> Signed-off-by: Jeff King <peff@peff.net>
> ---
> diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
> @@ -258,6 +258,13 @@ For C programs:
> + - When using DEVELOPER=1 mode, you may see warnings from the compiler
> +   like "error: unused parameter 'foo' [-Werror=unused-parameter]",
> +   which indicates that a function ignores its argument. If the unused
> +   parameter can't be removed (e.g., because the function is used as a
> +   callback and has to match a certain interface), you can annotate the
> +   individual parameters with the UNUSED keyword, like "int foo UNUSED".

Perfect. This fully addresses the question expressed by my review
comment. Thank you.

  reply	other threads:[~2024-08-28 19:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-28  3:57 [PATCH 0/6] unused parameters: the final countdown Jeff King
2024-08-28  3:57 ` [PATCH 1/6] gc: mark unused config parameter in virtual functions Jeff King
2024-08-28  3:57 ` [PATCH 2/6] t-reftable-readwrite: mark unused parameter in callback function Jeff King
2024-08-28  3:58 ` [PATCH 3/6] compat: disable -Wunused-parameter in 3rd-party code Jeff King
2024-08-28  3:59 ` [PATCH 4/6] compat: disable -Wunused-parameter in win32/headless.c Jeff King
2024-08-28  4:00 ` [PATCH 5/6] compat: mark unused parameters in win32/mingw functions Jeff King
2024-08-28  4:00 ` [PATCH 6/6] config.mak.dev: enable -Wunused-parameter by default Jeff King
2024-08-28  5:56   ` Eric Sunshine
2024-08-28  8:21     ` Patrick Steinhardt
2024-08-28 14:48     ` [PATCH 7/6] CodingGuidelines: mention -Wunused-parameter and UNUSED Jeff King
2024-08-28 19:53       ` Eric Sunshine [this message]
2024-08-28 15:17     ` [PATCH 6/6] config.mak.dev: enable -Wunused-parameter by default Junio C Hamano
2024-08-28  4:12 ` [PATCH 0/6] unused parameters: the final countdown Jeff King

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=CAPig+cSBPxtv50KknJVbucAa9RGxQxP66XHpjCjECWdSGPRHjw@mail.gmail.com \
    --to=sunshine@sunshineco.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).