2018-11-07 16:48:05

by Mike Rapoport

Subject: [PATCH v2 0/2] kernel-doc: extend $type_param to match members referenced by pointer

Hi,

v2: separate whitespace and functional changes

Mike Rapoport (2):
kernel-doc: kill trailing whitespace
kernel-doc: extend $type_param to match members referenced by pointer

scripts/kernel-doc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--
2.7.4

2018-11-07 16:48:09

by Mike Rapoport

Subject: [PATCH v2 1/2] kernel-doc: kill trailing whitespace

Signed-off-by: Mike Rapoport <[email protected]>
---
scripts/kernel-doc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index ffbe901..24d3550 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -361,7 +361,7 @@ my $doc_com = '\s*\*\s*';
my $doc_com_body = '\s*\* ?';
my $doc_decl = $doc_com . '(\w+)';
# @params and a strictly limited set of supported section names
-my $doc_sect = $doc_com .
+my $doc_sect = $doc_com .
'\s*(\@[.\w]+|\@\.\.\.|description|context|returns?|notes?|examples?)\s*:(.*)';
my $doc_content = $doc_com_body . '(.*)';
my $doc_block = $doc_com . 'DOC:\s*(.*)?';
@@ -751,7 +751,7 @@ sub output_blockhead_rst(%) {

#
# Apply the RST highlights to a sub-block of text.
-#
+#
sub highlight_block($) {
# The dohighlight kludge requires the text be called $contents
my $contents = shift;
--
2.7.4

2018-11-07 16:48:15

by Mike Rapoport

Subject: [PATCH v2 2/2] kernel-doc: extend $type_param to match members referenced by pointer

Currently, function parameter description can match '@type.member'
expressions but fails to match '@type->member'.
Extend the $type_param regex to allow matching both

Signed-off-by: Mike Rapoport <[email protected]>
---
scripts/kernel-doc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 24d3550..f9f1431 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -212,7 +212,7 @@ my $anon_struct_union = 0;
my $type_constant = '\b``([^\`]+)``\b';
my $type_constant2 = '\%([-_\w]+)';
my $type_func = '(\w+)\(\)';
-my $type_param = '\@(\w*(\.\w+)*(\.\.\.)?)';
+my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
my $type_fp_param = '\@(\w+)\(\)'; # Special RST handling for func ptr params
my $type_env = '(\$\w+)';
my $type_enum = '\&(enum\s*([_\w]+))';
--
2.7.4

2018-11-07 19:40:30

by Markus Heiser

Subject: Re: [PATCH v2 2/2] kernel-doc: extend $type_param to match members referenced by pointer

Am 07.11.18 um 17:47 schrieb Mike Rapoport:
> Currently, function parameter description can match '@type.member'
> expressions but fails to match '@type->member'.
> Extend the $type_param regex to allow matching both
>
> Signed-off-by: Mike Rapoport <[email protected]>
> ---
> scripts/kernel-doc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 24d3550..f9f1431 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -212,7 +212,7 @@ my $anon_struct_union = 0;
> my $type_constant = '\b``([^\`]+)``\b';
> my $type_constant2 = '\%([-_\w]+)';
> my $type_func = '(\w+)\(\)';
> -my $type_param = '\@(\w*(\.\w+)*(\.\.\.)?)';
> +my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';

Thanks, works! FWIW: added [1] this to the linuxdoc project (a kernel-doc
spinoff). There we have a small frmaework for testing kernel-doc patches [2].
Which found a few hundert usages of '->' pointers in the whole kernel sources.

[1] https://github.com/return42/linuxdoc/commit/cce336ce0
[2] https://github.com/return42/linuxdoc/blob/master/Makefile#L95

-- Markus --

2018-11-07 22:48:37

by Jonathan Corbet

Subject: Re: [PATCH v2 2/2] kernel-doc: extend $type_param to match members referenced by pointer

On Wed, 7 Nov 2018 18:47:13 +0200
Mike Rapoport <[email protected]> wrote:

> Currently, function parameter description can match '@type.member'
> expressions but fails to match '@type->member'.
> Extend the $type_param regex to allow matching both
>
> Signed-off-by: Mike Rapoport <[email protected]>

That makes a lot of changes to the generated output but, as far as I can
tell, they're all correct. A definite improvement. Applied, thanks.

jon