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

[MyDeveloper Day via llvm-dev]

@Timothy Keith,

Through this I've become aware of several sub-projects/libs that are either
100% clean or near 100% clean (flang,milr)

I have my own internal 5 million line code base which is 100%
clang-formatted (including all C# and JS, unit tests), plus Firefox is also
I think 100% converted, some helpful devs over there pull some patches and
check for regressions if I add them as reviewers.

I always knew "polly" was mostly clean too, and actually one of the areas I
already test against, (along with lib/Format obviously).

If we could get whole sub-projects 100% clean then it would be possible for
me to notify them downstream when a clang-format change (for a bug fix)
requires an update. But without that 100% status I'm always playing a game
of checking every change, once we are at sub-project at 100% any change in
formatting can be identified as a potential bug.

The current process I'm building is for the script that generates that html
page to also generate a list of directories that are 100% clean, then use
that as input to a test which validates clang-format, any clang-format
replacements signify either recent unformatted changes or potentially bug
fixes or regressions. (all of which in my view are worth highlighting to
either clang-format or the owners of the subprojects)

Where sub teams can help is by making their projects 100% clean and helping
to enforce/maintain that. We really try to not change LLVM default style
but I am trying to work my way through the bugs and that from time to time
does show differences. ideally I would run this regression on your
sub-projects and then @mention your Phabricator project that inside review.
(or send a review of the changes)

This is not about imposing style on anyone, It is purely about ensuring we
don't break the world as fixing bugs inevitably causes some instability.
However one wrong move could have massive ripples through all the projects
that use clang-format, the unit tests are excellent but regressions still
slip through the net, and we already had a case where v10 had an issue
which impacted others after it had been branched. I feel we need to ensure
clang-format is run over millions of lines of code to catch bugs as early
as possible. (and to root out new ones), it will be of huge benefit to
clang-format if our own code base is heavily formatted so I really
appreciate those who consider this worthwhile.

MyDeveloperDay


On Wed, Jul 1, 2020 at 12:54 AM Timothy Keith <tkeith at nvidia.com> wrote:

> The flang sub-project is supposed to be fully formatted so it wouldn’t be
> hard to get to 100% for a test like this and we would be happy to
> participate. We were at 100% at one point but there are about 10 files that
> need formatting now, in part because of changes to clang-format. It would
> be good to get early warning of clang-format changes like that.
>
>
>
> Let me know if there is anything I can do to help.
>
>
>
> Tim
>
>
>
> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Chris
> Lattner via llvm-dev <llvm-dev at lists.llvm.org>
>
> On Jun 28, 2020, at 8:30 AM, 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
> <http://clang.llvm.org/docs/ClangFormattedStatus.html> to track the
> status of “How Much” clang-formatted the
>
> LLVM/Clang project is.
>
> Wow, I hadn’t seen this - this is really cool!
>
>
>
> 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.
>
> I’m a huge fan of clang-format, and have worked in “required to be
> formatted” code bases - it is a way better way to work in my opinion.  That
> said, such a move that you’re talking about is something that will take
> time, because this is a social problem as well as a technical one.
>
>
>
> Instead of starting from a “can we do everything” question (which you’re
> already getting some “no’s”), I’d start with an easier question of “is
> anyone ok with mechanically formatting *any* pieces of llvm?”  There will
> be some folks (e.g. the MLIR ones, perhaps the flang ones?) that are more
> likely to be early adopters, and this gives the opportunity to figure out
> policies and tools to help maintain things.  Then you can move on to other
> subdirectories within llvm/clang/etc, and progressively get there.
>
>
>
> This helps achieve your goal of getting more of the stack, but avoids it
> being an “all or nothing” sort of dichotomy.
>
>
>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200701/b3aff07f/attachment-0001.html>