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

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

[Mike Rapoport]

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

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

[Mike Rapoport]

Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
---
 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

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

[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 <rppt@linux.ibm.com>
---
 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

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

[Markus Heiser]

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 <rppt@linux.ibm.com>
> ---
>   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 --

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

[Jonathan Corbet]

On Wed,  7 Nov 2018 18:47:13 +0200
Mike Rapoport <rppt@linux.ibm.com> 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 <rppt@linux.ibm.com>

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