[llvm-dev] [RFC] Semi-Automatic clang-format of files with low frequency

[Philip Reames via llvm-dev]

A couple of points for consideration.  Fair warning, I have not read the 
full discussion down thread, these might have already been raised.

 1. File granularity is the wrong scope to be thinking in.  A file which
    is 99% clang formatted is much better than one which is 1%
    clang-formatted.  Any system which tries to automatically generate
    patches should think in terms of scopes (functions, classes), and
    propose changes based on the age of that code, not the age of the file.
 2. Formatting changes (of this particular proposed type) should
    definitely be reviewed.  This allows different areas of the code
    base to move at different paces based on the relative importance
    assigned by the knowledgeable reviewers.
     1. The rate of submission should be strictly rate limited on a per
        reviewer basis.  (i.e. 100 outstanding reviews w/100 distinct
        reviewers is very different than hitting one person with 100
        reviews)
     2. To make this practical, someone needs to own the rebase and land
        after approval process.  This could be automated (github PR
        anyone), but is not optional.  The workflow for reviewer must be
        "approve and never think about again".
     3. The option to reject permanently a proposed change must be a
        first class outcome.  This can be done either by using explicit
        markers in code, or by maintaining an external "no-format"
        list.  Having this list public - since there's likely to be
        disagreement about items on it - is good.
     4. Someone must also commit to shepard the reviews.  Objections to
        formatting must be addressed proactively.  (e.g. changes made to
        format config file) not simply yelled into the the ether.
 3. The goal of such a system should not be to test clang-format. If you
    want a test corpus, create one in a fork.  The only motivation we
    should consider is if it improves the development productivity of
    our engineers or the quality of our code base. (I happen to think
    it's likely to do both.)

Of, and in case it's not obvious, I generally think that a well managed 
system is valuable here.  If someone wants to sign up to drive the 
non-trivial amount of work required here, awesome!

Philip

On 6/28/20 8:30 AM, MyDeveloper Day via llvm-dev wrote:
>
> (Copying from Discourse)
>
> All
>
> A couple of months ago I added the following page documentation 
> Clang-Formatted-Status 
> <http://clang.llvm.org/docs/ClangFormattedStatus.html> to track the 
> status of “How Much” clang-formatted the
>
> LLVM/Clang project is.
>
> I’m a contributor to clang-format and would like to see LLVM 100% 
> clang formatted so we can use LLVM as a massive test-suite for 
> clang-format when we make changes.
>
> In the last couple of months since we added this page the % has gone 
> up by ~4% and this is likely in most part of either: a mention in 
> LLVM-Weekly, the premerge checks or perhaps some recent clang-format 
> efforts by individuals. This is fantastic and every directory that 
> gets to 100% increase the directories that I can run against to check 
> against.
>
> However, it recently twigged to me that files that don’t change very 
> often are never going to be 100% clang-formatted simply by virtue of 
> clang-formatting all new changes.
>
> So I 100% understand this kind of topic comes up from time to time and 
> I understand that we don’t want to automatically clang-format the 
> entire tree as this can disrupt peoples downstream forks, especially 
> where they actively have code inflight.
>
> But I wonder if we could have a general rule that said a [NFC] 
> clang-format change could be made on ANY file that had NOT been 
> changed in a 6/12 months period? I believe this process could be 
> automated at least in a semi-automatic way. Once complete the 
> pre-merge checks should maintain the current status.
>
> This would drive the goal of completely clang-formatted source tree, 
> without the disruption to current active areas.
>
> Any thoughts?
>
> MyDeveloperDay
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200701/f1e2e4be/attachment.html>