Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [RFC] scripts: kernel-doc: fix typedef support for struct parsing
To:     Jonathan Corbet <corbet@lwn.net>
Cc:     lukas.bulwahn@gmail.com, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        linux-kernel-mentees@lists.linuxfoundation.org
References: <20210222160347.23410-1-yashsri421@gmail.com>
 <875z2jlr2j.fsf@meer.lwn.net>
From:   Aditya <yashsri421@gmail.com>
Message-ID: <19d41289-cf8e-881d-cc0d-9c7e193db242@gmail.com>
Date:   Tue, 23 Feb 2021 17:55:36 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <875z2jlr2j.fsf@meer.lwn.net>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 23/2/21 3:10 am, Jonathan Corbet wrote:
> Aditya Srivastava <yashsri421@gmail.com> writes:
> 
>> There are files in kernel, which use 'typedef struct' syntax for defining
>> struct. For eg, include/linux/zstd.h, drivers/scsi/megaraid/mega_common.h,
>> etc.
>> However, kernel-doc still does not support it, causing a parsing error.
>>
>> For eg, running scripts/kernel-doc -none on include/linux/zstd.h emits:
>> "error: Cannot parse struct or union!"
>>
>> Add support for parsing it.
>>
>> Signed-off-by: Aditya Srivastava <yashsri421@gmail.com>
>> ---
>>  scripts/kernel-doc | 12 ++++++++++--
>>  1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
>> index 8b5bc7bf4bb8..46e904dc3f87 100755
>> --- a/scripts/kernel-doc
>> +++ b/scripts/kernel-doc
>> @@ -1201,12 +1201,20 @@ sub dump_union($$) {
>>  sub dump_struct($$) {
>>      my $x = shift;
>>      my $file = shift;
>> +    my $decl_type;
>> +    my $members;
>>  
>>      if ($x =~ /(struct|union)\s+(\w+)\s*\{(.*)\}(\s*(__packed|__aligned|____cacheline_aligned_in_smp|____cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*/) {
>> -	my $decl_type = $1;
>> +	$decl_type = $1;
>>  	$declaration_name = $2;
>> -	my $members = $3;
>> +	$members = $3;
>> +    } elsif ($x =~ /typedef\s+(struct|union)\s*\{(.*)\}(?:\s*(?:__packed|__aligned|____cacheline_aligned_in_smp|____cacheline_aligned|__attribute__\s*\(\([a-z0-9,_\s\(\)]*\)\)))*\s*(\w*)\s*;/) {
> 
> So this isn't your fault, but these regexes are really getting out of
> hand.  I would *really* like to see some effort made into making this
> code more understandable / maintainable as we tweak this stuff.  So:
> 
>  - Splitting out the common part, as suggested by Lukas, would be really
>    useful.  That would also avoid the problem of only occurrence being
>    edited the next tine we add a new qualifier.
> 
>  - Splitting out other subsections of the regex and giving them symbolic
>    names would also help.
> 
>  - We really could use some comments before these branches saying what
>    they are doing; it is *not* obvious from the code.
> 
> See what I'm getting at here?
> 
Yep.
Thanks for the feedback Lukas and Jonathan. I'll get back with a v2
for the patch.

Thanks
Aditya