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

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<mailto: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/20200630/7db999e0/attachment.html>

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

On Wed, Jul 1, 2020 at 3:46 AM MyDeveloper Day via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> @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.
I'm still curious/confused why this requires (or significantly
benefits from) actual 3rd party code to be clang-formatted in the
projects (LLVM and otherwise) themselves. Compared to clang-formatting
such a codebase on a branch (possibly even a local branch) with an old
clang-format and a new one, and checking any deltas are desirable?

- Dave
>
> 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 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
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Am Mi., 1. Juli 2020 um 05:46 Uhr schrieb MyDeveloper Day via llvm-dev
<llvm-dev at lists.llvm.org>:
> I always knew "polly" was mostly clean too, and actually one of
the areas I already test against, (along with lib/Format obviously).
You have no other choice.
Polly verifies its source formatting as part of check-polly, so every
commit that violates formatting will get an email from the buildbot.It
also triggers when clang-format itself changes. Did you find those
helpful?

The parts of Polly that are left out are its external dependencies,
i.e. isl and imath. I wonder why these are even included in the
clang-format status, we certainly do not want to modify these source
files.

For clang, I have to exclude the test folder because clang-format
messes with clang -verify tests that require comments on specific
lines and tests that check correct behavior of clang on whitespace.


Michael