[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210119084328.749e415f@coco.lan>
Date: Tue, 19 Jan 2021 08:43:49 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Jonathan Corbet <corbet@....net>
Cc: Linux Doc Mailing List <linux-doc@...r.kernel.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 11/16] scripts: kernel-doc: validate kernel-doc
markup with the actual names
Em Mon, 18 Jan 2021 13:35:45 -0700
Jonathan Corbet <corbet@....net> escreveu:
> On Thu, 14 Jan 2021 09:04:47 +0100
> Mauro Carvalho Chehab <mchehab+huawei@...nel.org> wrote:
>
> > Kernel-doc currently expects that the kernel-doc markup to come
> > just before the function/enum/struct/union/typedef prototype.
> >
> > Yet, if it find things like:
> >
> > /**
> > * refcount_add - add a value to a refcount
> > * @i: the value to add to the refcount
> > * @r: the refcount
> > */
> > static inline void __refcount_add(int i, refcount_t *r, int *oldp);
> > static inline void refcount_add(int i, refcount_t *r);
> >
> > Kernel-doc will do the wrong thing:
> >
> > foobar.h:6: warning: Function parameter or member 'oldp' not described in '__refcount_add'
> > .. c:function:: void __refcount_add (int i, refcount_t *r, int *oldp)
> >
> > add a value to a refcount
> >
> > **Parameters**
> >
> > ``int i``
> > the value to add to the refcount
> >
> > ``refcount_t *r``
> > the refcount
> >
> > ``int *oldp``
> > *undescribed*
> >
> > Basically, it will document "__refcount_add" with the kernel-doc
> > markup for refcount_add.
> >
> > If both functions have the same arguments, this won't even
> > produce any warning!
> >
> > Add a logic to check if the kernel-doc identifier matches the actual
> > name of the C function or data structure that will be documented.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
>
> I've applied this one;
Thanks!
> it seems useful to have even if it creates more
> warnings that Stephen will duly email me about tomorrow...:) I have parts
> 1-10 set aside and will apply any that don't get picked up directly by the
> maintainers involved.
Yeah, new warnings are unavoidable, as new patches may be introducing
extra issues. Hopefully, the new warning will help people to detect
the issue earlier before submitting upstream.
Thanks,
Mauro
Powered by blists - more mailing lists