workflows.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mac Xu <mac.xxn@outlook.com>
To: Joe Perches <joe@perches.com>, Barry Song <21cnbao@gmail.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Cc: "apw@canonical.com" <apw@canonical.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"chenhuacai@loongson.cn" <chenhuacai@loongson.cn>,
	"chris@zankel.net" <chris@zankel.net>,
	"corbet@lwn.net" <corbet@lwn.net>,
	"dwaipayanray1@gmail.com" <dwaipayanray1@gmail.com>,
	"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux@roeck-us.net" <linux@roeck-us.net>,
	"lukas.bulwahn@gmail.com" <lukas.bulwahn@gmail.com>,
	"sfr@canb.auug.org.au" <sfr@canb.auug.org.au>,
	"v-songbaohua@oppo.com" <v-songbaohua@oppo.com>,
	"workflows@vger.kernel.org" <workflows@vger.kernel.org>,
	Max Filippov <jcmvbkbc@gmail.com>
Subject: Re: [PATCH v4 2/2] scripts: checkpatch: check unused parameters for function-like macro
Date: Sun, 31 Mar 2024 13:43:33 +0000	[thread overview]
Message-ID: <MN0PR20MB47171D2D78C8E71286E133BCF3382@MN0PR20MB4717.namprd20.prod.outlook.com> (raw)
In-Reply-To: <ef2c96e40bcf777535c9ff2405e4dc5b3138b27e.camel@perches.com>


> On Thu, 2024-03-28 at 15:21 +1300, Barry Song wrote:
> > From: Xining Xu <mac.xxn@outlook.com>
> >
> > If function-like macros do not utilize a parameter, it might result in a
> > build warning.  In our coding style guidelines, we advocate for utilizing
> > static inline functions to replace such macros.  This patch verifies
> > compliance with the new rule.
> []
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> []
> > @@ -6109,6 +6109,36 @@ sub process {
> >                                WARN("TRAILING_SEMICOLON",
> >                                     "macros should not use a trailing semicolon\n" . "$herectx");
> >                        }
> > +
> > +                     # match "\s*" rather than "\s+" after the balanced parens, as macro definition with arguments
> > +                     # is not required to have whitespace after arguments
> > +                     if ($dstat =~ /^\+\s*#\s*define\s+$Ident$balanced_parens\s*(\S+.*)(\/[\/*].*)?/) {
> 
> I think '(\/[\/*].*)?' doesn't do what you expect
> perhaps '(\/[\/\*].*)?'
> though I don't know why this should be capture group

I'd wanted to capture the comment to handle a case where a unused param happens to appears in a comment

> 
> > +                             my $params = $1 || "";
> 
> 
> > +                             my $body = $2 || "";
> 
> Should never get the || "" as the 2nd capture group is not optional
> 
> > +
> > +                         # get the individual params
> > +                             $params =~ tr/()//d;
> > +                             # remove leading and trailing whitespace
> > +                             $params =~ s/^\s+|\s+$//g;
> > +
> > +                             $ctx =~ s/\n*$//;
> > +                             my $cnt = statement_rawlines($ctx);
> > +                             my $herectx = get_stat_here($linenr, $cnt, $here);
> > +
> > +                             if ($params ne "") {
> 
> probably unnecessary
> 
> > +                                     my @paramList = split /,\s*/, $params;
> 
> please use split() with parentheses
> 
> > +                                     foreach my $param(@paramList) {
> 
> maybe
>                                 foreach my $param (split(/,/, $params) {
>                                         $param = trim($param);
>                                         next if ($param =~ /\.\.\.$/);
> > +                                             if ($param =~ /\.\.\.$/) {
> > +                                                     # if the param name ends with "...", skip the check
> > +                                                     next;
> > +                                             }
> > +                                             if ($body !~ /\b$param\b/) {
> > +                                                     WARN("UNUSED_PARAM_IN_MACRO",
> > +                                                             "Parameter '$param' is not used in function-like macro\n" . "$herectx");
> > +                                             }
> > +                                     }
> It seems this logic is a bit redundant to existing
> code and might be better added in the block that starts
> 
> (line 6026)
> # check if any macro arguments are reused (ignore '...' and 'type')
> 
> as that already does each param in a #define and
> ignores ... and type

Hi Joe,

Thank you for your comments with insights, as you said, code block of line 6026 is a better place to 
place this new logic, as it already handles the logic I'd wanted like extracting, splitting and trimming 
the arguments, excluding the trailing comments etc.

By placing the logic in the new place, code duplicates are drastically reduced.

Here's my new code (inserted from line 6044):
+# check if this is an unused argument
+        if ($define_stmt !~ /\b$arg\b/) {
+                WARN("UNUSED_ARG_IN_MACRO",
+                        "Argument '$arg' is not used in function-like macro\n" . "$herectx");
+        }
+}

Please note that I use the wording of "arg/argument" instead of "param/parameter" for consistency, 
please let me know if if this is the correct wording to use here.

Thanks,
Mac.


  reply	other threads:[~2024-03-31 13:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-28  2:21 [PATCH v4 0/2] codingstyle: avoid unused parameters for a function-like macro Barry Song
2024-03-28  2:21 ` [PATCH v4 1/2] Documentation: coding-style: ask function-like macros to evaluate parameters Barry Song
2024-03-28  2:21 ` [PATCH v4 2/2] scripts: checkpatch: check unused parameters for function-like macro Barry Song
2024-03-28  9:57   ` Joe Perches
2024-03-31 13:43     ` Mac Xu [this message]
2024-03-31 13:46     ` Mac Xu
2024-03-31 15:54       ` Joe Perches
2024-03-31 23:21         ` Mac Xu
2024-03-28 16:01   ` Jeff Johnson
2024-03-28 21:24     ` Barry Song
2024-03-28  4:22 ` [PATCH v4 0/2] codingstyle: avoid unused parameters for a " Barry Song

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=MN0PR20MB47171D2D78C8E71286E133BCF3382@MN0PR20MB4717.namprd20.prod.outlook.com \
    --to=mac.xxn@outlook.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=broonie@kernel.org \
    --cc=chenhuacai@loongson.cn \
    --cc=chris@zankel.net \
    --cc=corbet@lwn.net \
    --cc=dwaipayanray1@gmail.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jcmvbkbc@gmail.com \
    --cc=joe@perches.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lukas.bulwahn@gmail.com \
    --cc=sfr@canb.auug.org.au \
    --cc=v-songbaohua@oppo.com \
    --cc=workflows@vger.kernel.org \
    /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).