On Sat, Oct 05, 2019 at 09:31:23PM +0200, Jonathan Neuschäfer wrote:
> On Sat, Oct 05, 2019 at 06:33:30AM -0700, Paul E. McKenney wrote:
> > On Sat, Oct 05, 2019 at 01:23:28AM +0200, Jonathan Neuschäfer wrote:
> > > On Fri, Oct 04, 2019 at 03:24:39PM -0700, Paul E. McKenney wrote:
> > > > On Fri, Oct 04, 2019 at 11:54:02PM +0200, Jonathan Neuschäfer wrote:
> > > > > Without this patch, Sphinx shows "variable arguments" as the 
> > > > > description
> > > > > of the cond argument, rather than the intended description, and prints
> > > > > the following warnings:
> > > > > 
> > > > > ./include/linux/rculist.h:374: warning: Excess function parameter 
> > > > > 'cond' description in 'list_for_each_entry_rcu'
> > > > > ./include/linux/rculist.h:651: warning: Excess function parameter 
> > > > > 'cond' description in 'hlist_for_each_entry_rcu'
> > > 
> > > Hmm, small detail that I didn't realize before: It's actually the
> > > kernel-doc script, not Sphinx, that can't deal with variadic macro
> > > arguments and thus requires this patch.
> > > 
> > > So it may also be possible to fix the script instead. (I have not
> > > looked into how much work that would be.)
> > 
> > OK, thank you for letting me know.  I will keep your patch for the
> > moment, but please let me know if the fix can be elsewhere.
> > 
> >                                                     Thanx, Paul
> 
> Turns out the actual fix in scripts/kernel-doc is easy enough:
> 
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -1449,6 +1449,10 @@ sub push_parameter($$$$) {
>             # handles unnamed variable parameters
>             $param = "...";
>           }
> +         elsif ($param =~ /\w\.\.\.$/) {
> +           # for named variable parameters of the form `x...`, remove the 
> dots
> +           $param =~ s/\.\.\.$//;
> +         }
>           if (!defined $parameterdescs{$param} || $parameterdescs{$param} eq 
> "") {
>               $parameterdescs{$param} = "variable arguments";
>           }
> 
> ... but there are other macros in the code base that are documented
> using the 'x...' syntax, so I guess it's best to take my initial patch
> (or something similar) now, and I'll fix kernel-doc later, in a longer
> patchset that also cleans up the fallout.

You got it!  ;-)

                                                        Thanx, Paul

Reply via email to