[llvm-dev] [RFC] Semi-Automatic clang-format of files with low frequency
MyDeveloper Day via llvm-dev
llvm-dev at lists.llvm.org
Sun Jun 28 08:30:44 PDT 2020
(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200628/28ed831f/attachment-0001.html>
More information about the llvm-dev
mailing list