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.
next prev parent 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).