On Tue, 27 Oct 2020, trix@redhat.com wrote:
This rfc will describe An upcoming treewide cleanup. How clang tooling was used to programatically do the clean up. Solicit opinions on how to generally use clang tooling.
This tooling is very impressive. It makes possible an idea that I had a while ago, to help make code review more efficient. It works like this.
Suppose a patch, p, is the difference between the new tree, n, and the old tree, o. That is, p = n - o.
Now let clang-tidy be the transformation 't'. This gets you a much more readable patch submission, P = t(n) - t(o).
The only difficulty is that, if I submit P intead of p then 'git am' will probably reject it. This is solved by a little tooling around git, such that, should a patch P fail to apply, the relevant files are automatically reformatted with the officially endorsed transformation t, to generate a minimal cleanup patch, such that P can be automatically applied on top.
If the patch submission process required* that every patch submission was generated like P and not like p, it would immediately eliminate all clean-up patches from the workload of all reviewers, and also make the reviewers' job easier because all submissions are now formatted correctly, and also avoid time lost to round-trips, such as, "you can have a reviewed-by if you respin to fix some minor style issues".
* Enforcing this, e.g. with checkpatch, is slightly more complicated, but it works the same way: generate a minimal cleanup patch for the relevant files, apply the patch-to-be-submitted, and finally confirm that the modified files are unchanged under t.