Re: Subject: [RFC] clang tooling cleanups

[Tom Rix]

On 10/27/20 12:51 PM, Joe Perches wrote:
> (Adding Stephen Rothwell)
>
> On Tue, 2020-10-27 at 12:33 -0700, Tom Rix wrote:
>> On 10/27/20 11:42 AM, Nick Desaulniers wrote:
>>> (cutting down the CC list to something more intimate)
> []
>
>> I am interested in treewide fixes.
> As am I, but here the definition of fixes is undefined though.
> Whitespace / style changes and other bits that don't change generated
> object code aren't considered fixes by many maintainers.
>
>> Cleaning them up (maybe me not doing all the patches) and keeping them clean.
>>
>> The clang -Wextra-semi-stmt -fixit will fix all 10,000 problems
> I rather doubt there are 10K extra semicolons in the kernel source tree.
> Is there a proposed diff/patch posted somewhere?

Not as-such, the number comes from adding -Wextra-semi-stmt to a clang allyesconfig.

grepping and sorting unique warnings.

I did a similar over view for no newlines at end of file and unneeded breaks which

turned up 2 and ~250 problems.

>
>> This clang tidy fixer will fix only the 100 problems that are 'switch() {};'
>>
>> When doing a treewide cleanup, batching a bunch of fixes that are the same problem and fix 
>> is much easier on everyone to review and more likely to be accepted.
> That depends on the definition of batching.
>
> If individual patches are sent to multiple maintainers, the
> acceptance / apply rate seems always < 50% and some are rejected
> outright by various maintainers as "unnecessary churn".
>
> Single treewide patches are generally not applied unless by Linus.
> The trivial tree isn't widely used for this.
>
> Perhaps a 'scripted' git tree could be established that is integrated
> into -next that would allow these automated patches to be better
> vetted and increase the acceptance rate of these automated patches.
>
>> Long term, a c/i system would keep the tree clean by running the switch-semi checker/fixer. 
>> And we can all move onto the next problem.
> Good idea...
> I hope a scripted patches mechanism will be established.

I would be interested in this as well.

I already have a repo tracking next.

I can code up a script to do the commits.

Then we can poke at it with sticks and see if hooking it into next is worthwhile.

Tom

>
>