Messages in this thread | | | Subject | Re: Subject: [RFC] clang tooling cleanups | From | Tom Rix <> | Date | Tue, 27 Oct 2020 14:09:31 -0700 |
| |
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
> >
| |