From: Mauro Carvalho Chehab <mchehab@s-opensource.com>
To: Markus Heiser <markus.heiser@darmarit.de>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v3] docs-rst: ignore arguments on macro definitions
Date: Mon, 29 Aug 2016 12:13:26 -0300 [thread overview]
Message-ID: <20160829121326.782e4261@vento.lan> (raw)
In-Reply-To: <BBC1BC77-BCF1-453C-B85D-9758C4C433A6@darmarit.de>
Em Mon, 29 Aug 2016 16:12:39 +0200
Markus Heiser <markus.heiser@darmarit.de> escreveu:
> Am 29.08.2016 um 15:13 schrieb Mauro Carvalho Chehab <mchehab@s-opensource.com>:
>
> > A macro definition is mapped via .. c:function:: at the
> > ReST markup when using the following kernel-doc tag:
> >
> > /**
> > * DMX_FE_ENTRY - Casts elements in the list of registered
> > * front-ends from the generic type struct list_head
> > * to the type * struct dmx_frontend
> > *
> > * @list: list of struct dmx_frontend
> > */
> > #define DMX_FE_ENTRY(list) \
> > list_entry(list, struct dmx_frontend, connectivity_list)
> >
> > However, unlike a function description, the arguments of a macro
> > doesn't contain the data type.
> >
> > This causes warnings when enabling Sphinx on nitkpick mode,
> > like this one:
> > ./drivers/media/dvb-core/demux.h:358: WARNING: c:type reference target not found: list
>
> I think this is a drawback of sphinx's C-domain, using function
> definition for macros also. From the function documentation
>
> """This is also used to describe function-like preprocessor
> macros. The names of the arguments should be given so
> they may be used in the description."""
>
> I think about to fix the nitpick message for macros (aka function
> directive) in the C-domain extension (we already have).
Yeah, that could produce a better output, if it is doable.
>
> But for this, I need a rule to distinguish between macros
> and functions ... is the uppercase of the macro name a good
> rule to suppress the nitpick message?
No. There are lots of macros in lowercase. never did any stats about
that, but I guess that we actually have a way more such macros in
lowercase.
> Any other suggestions?
I guess the best thing is to check if the type is empty, just like
on this patch. Macros are always:
foo(arg1, arg2, arg3, ...)
while functions always have some type (with could be as complex as
a function pointer). So, if all arguments match this rejex:
\s*\S+\s*
Then, it is a macro. Otherwise, it is a function.
There's no way for the C domain to distinguish between a macro or
a function when the number of arguments is zero, but, on such case,
it doesn't really matter.
Thanks,
Mauro
next prev parent reply other threads:[~2016-08-29 15:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 13:13 [PATCH v3] docs-rst: ignore arguments on macro definitions Mauro Carvalho Chehab
2016-08-29 14:12 ` Markus Heiser
2016-08-29 15:13 ` Mauro Carvalho Chehab [this message]
2016-08-29 15:36 ` Jani Nikula
2016-08-31 8:15 ` Markus Heiser
2016-08-31 9:02 ` Jani Nikula
2016-08-31 10:09 ` Markus Heiser
2016-08-31 10:26 ` Mauro Carvalho Chehab
2016-08-31 10:37 ` Markus Heiser
2016-09-08 11:40 ` Mauro Carvalho Chehab
2016-09-08 13:58 ` Markus Heiser
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=20160829121326.782e4261@vento.lan \
--to=mchehab@s-opensource.com \
--cc=corbet@lwn.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=markus.heiser@darmarit.de \
--cc=mchehab@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 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).