From: Jonathan Corbet <corbet@lwn.net>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Kees Cook <keescook@chromium.org>,
Jani Nikula <jani.nikula@linux.intel.com>
Subject: Re: [PATCH] kernel-doc: fix declaration type determination
Date: Thu, 18 Oct 2018 12:21:55 -0600 [thread overview]
Message-ID: <20181018122155.4fe8dc01@lwn.net> (raw)
In-Reply-To: <640b26f4-a6fa-ffbc-c866-ea03de4f79a5@infradead.org>
On Wed, 17 Oct 2018 21:07:27 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Make declaration type determination more robust.
>
> When scripts/kernel-doc is deciding if some kernel-doc notation
> contains an enum, a struct, a union, a typedef, or a function,
> it does a pattern match on the beginning of the string, looking
> for a match with one of "struct", "union", "enum", or "typedef",
> and otherwise defaults to a function declaration type.
> However, if a function or a function-like macro has a name that
> begins with "struct" (e.g., struct_size()), then kernel-doc
> incorrectly decides that this is a struct declaration.
>
> Fix this by looking for the declaration type keywords having an
> ending word boundary (\b), so that "struct_size" will not match
> a struct declaration.
>
> I compared lots of html before/after output from core-api, driver-api,
> and networking. There were no differences in any of the files that
> I checked.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied, thanks.
jon
prev parent reply other threads:[~2018-10-18 18:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-18 4:07 [PATCH] kernel-doc: fix declaration type determination Randy Dunlap
2018-10-18 9:14 ` Jani Nikula
2018-10-18 18:21 ` Jonathan Corbet [this message]
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=20181018122155.4fe8dc01@lwn.net \
--to=corbet@lwn.net \
--cc=jani.nikula@linux.intel.com \
--cc=keescook@chromium.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.