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

[David Blaikie via llvm-dev]

On Mon, Jun 29, 2020 at 1:33 PM MyDeveloper Day via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> (Copying from Discourse)
>
> All
>
> A couple of months ago I added the following page documentation Clang-Formatted-Status 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.

For that purpose, would it be possible to fork LLVM and clang-format
the whole thing & then leave that fork stagnant except when testing
changes to clang-format & migrating it to newer formatting? What's the
benefit of using a live project for this testing?

> 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?

I don't think I'd exactly have a problem with this - but yeah, imagine
it might not be super popular either.

- Dave