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

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

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

In general, sounds okay to me, but one slight concern I have is that there
are some areas of code I've seen which are deliberately unformatted for
various reasons, quite often because the code looks much nicer in its
current state or similar. This of course might just mean a clang-format bug
fix/small behaviour adjustment etc is needed, or "do not format"
markers
needs adding. However, short of an audit of every file that might be
affected by this, it's hard to know when something might be affected
undesirably, so I'd be marginally against it being an automated approach
without some kind of manual reading of the changes involved.

James

On Mon, 29 Jun 2020 at 21:33, 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.
>
> 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/20200630/bf6ffb53/attachment-0001.html>

I’m in favor of this because, like you said, unless we do something like this,
we’ll never get there. Frankly, I think the inactive period should be much
shorter. I would even go so far as to say something like 1 month of inactivity.
This codebase is under heavy development, so any code under active development
will likely be touched in a 1 month period. 6-12 months will only catch the
truly stable code, but any code that only gets minimal changes will never reach
100% coverage.

I would also like to see a threshold (maybe on a per-file or per-subfolder level
of granularity) where once the coverage gets over the threshold, we just “rip
the band-aid off” and clang-format everything. Suppose we set the threshold at
90%, and Foo.cpp is over 90% formatted, we just format the entire file and be
done with it.

I’m sympathetic to the argument that these sorts of change make managing
downstreams more difficult, I maintain one myself.  However, I would argue that
finishing the formatting as fast as possible will reduce downstream pain because
after the codebase is completely formatted, it’ll just be done and there will be
no more formatting churn. As it stands, we constantly have to deal with
formatting changes because there’s always new ones.

Thanks,
   Christopher Tetreault

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
MyDeveloper Day via llvm-dev
Sent: Sunday, June 28, 2020 8:31 AM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] [llvm-dev] [RFC] Semi-Automatic clang-format of files with low
frequency


(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/20200630/4d79d399/attachment-0001.html>

On Tue, Jun 30, 2020 at 6:26 PM Chris Tetreault via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I’m in favor of this because, like you said, unless we do something like
this, we’ll never get there. Frankly, I think the inactive period should be much
shorter. I would even go so far as to say something like 1 month of inactivity.
This codebase is under heavy development, so any code under active development
will likely be touched in a 1 month period. 6-12 months will only catch the
truly stable code, but any code that only gets minimal changes will never reach
100% coverage.
Hard no on the shorter period. I have changes I'm working on for
several months at a time. 1 year is a minimum for this in my opinion.

> I’m sympathetic to the argument that these sorts of change make managing
downstreams more difficult, I maintain one myself.  However, I would argue that
finishing the formatting as fast as possible will reduce downstream pain because
after the codebase is completely formatted, it’ll just be done and there will be
no more formatting churn. As it stands, we constantly have to deal with
formatting changes because there’s always new ones.
First of all, we don't currently have to deal with constant formatting
changes, at least not in the part of the code that's relevant to
AMDGPU. Why? Because we follow the (good!) rule of avoiding gratuitous
churn. This works _fine_.

Second, these kinds of things never work out that way. You think you
change everything once, but for one thing, tastes and fashions change.
For another, you probably wouldn't capture everything that everybody
wants captured. This thread talks about clang-format. Fine, but other
people talk about changing variable naming styles, and so on.

Code style just doesn't matter that much, but churn does. Don't you
folks have more pressing matters to work on? If you're bored in your
current job, consider applying with us :P

Cheers,
Nicolai



>
>
>
> Thanks,
>
>    Christopher Tetreault
>
>
>
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
MyDeveloper Day via llvm-dev
> Sent: Sunday, June 28, 2020 8:31 AM
> To: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [EXT] [llvm-dev] [RFC] Semi-Automatic clang-format of files with
low frequency
>
>
>
> (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.
>
> 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


-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.

> On Jun 28, 2020, at 11:30, MyDeveloper Day via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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.
> 
> 
My main issue with this would be that clang-format does things that I don’t
believe are stated in the LLVM style guide and I also disagree with. There’s a
whole set of cases where it makes unwelcome changes to put things that were on
separate lines on a single line. Whenever I run clang-format, I typically git
checkout -p to discard all of these.

For example, it likes to take member initializer lists and pack them into as few
lines as possible. This is just asking for merge conflicts (e.g. AMDGPUSubtarget
has a ton of fields in it, and out of tree code is constantly adding new fields
for unreleased subtargets). It also mangles BuildMI calls, where I believe every
.add() should be on its own line, and stringing this into
BuildMI().addFoo().addBar() is way less readable.

I also believe it’s 4 space indent on line wraps differs from the stated 2 space
indent level (and this also disagrees with emacs llvm-style)

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/33eccf0e/attachment.html>

On 6/30/20 12:55 PM, Matt Arsenault via llvm-dev wrote:
>
>
>> On Jun 28, 2020, at 11:30, MyDeveloper Day via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>> 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.
>>
>>
>
> My main issue with this would be that clang-format does things that I 
> don’t believe are stated in the LLVM style guide and I also disagree 
> with. There’s a whole set of cases where it makes unwelcome changes to 
> put things that were on separate lines on a single line. Whenever I 
> run clang-format, I typically git checkout -p to discard all of these.
>
> For example, it likes to take member initializer lists and pack them 
> into as few lines as possible. This is just asking for merge conflicts 
> (e.g. AMDGPUSubtarget has a ton of fields in it, and out of tree code 
> is constantly adding new fields for unreleased subtargets). It also 
> mangles BuildMI calls, where I believe every .add() should be on its 
> own line, and stringing this into BuildMI().addFoo().addBar() is way 
> less readable.

I agree that this is problematic. There are a number of places where 
repeated syntactic structures (e.g., in enums, initializers, 
chained-operator invocation) are represented using regular line offsets 
and line breaks. This is valuable, allows for semantically-relevant 
grouping, and in my opinion, enhances readability. I've certainly caught 
bugs in code that I've written because they became obvious once I lined 
everything up. Can clang-format be taught to format things in this way? 
For particular, long sections of code, I can imagine using some 
don't-format-here markers, but you wouldn't want these around every 
BuildMI(...) call.

  -Hal

>
> I also believe it’s 4 space indent on line wraps differs from the 
> stated 2 space indent level (and this also disagrees with emacs 
> llvm-style)
>
> -Matt
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/738df1ca/attachment-0001.html>

I 100% get that we might not like the decisions clang-format is making, but
how does one overcome this when adding new code? The pre-merge checks
enforce clang-formatting before commit and that's a common review comment
anyway for those who didn't join the pre-merge checking group. I'm just
wondering are we not all following the same guidelines?

Concerns of clang-format not being good enough are fair enough, but that's
the area I'm focusing my development efforts on (as that's where
I've been
trying to make a small contribution). This effort was driven out of a need
in my view to have an extensive test suite to validate new changes to
clang-format don't break the formatting of pre-formatted code. This
isn't
that possible with LLVM at the moment because large parts are not formatted.

However checking a code base which is in high flux but one that maintains a
100% clang-format clean status, is a near perfect test-suite. Especially
one that I assume will have unit tests for the latest C++ features.

I'm not bored ;-) and whilst I understand this feels somewhat periphery to
the seemingly much more pressing task of developing the next best compiler,
I think we have to remember that clang-format is extensively used. (In my
view by many more people than those actually using clang). GitHub reports
32,000 YAML files with the BasedOnStyle: LLVM alone that is present in the
.clang-format file

I realize it feels like unnecessary churn which is why I suggested this be
in code which hasn't been touched in some time (I'd be fine if that time
is
1+ years), but more often than not this is quite small basic style issues,
similar to the ones below.

MyDeveloperDay

-  void HandleTranslationUnit(ASTContext& context) override {
+  void HandleTranslationUnit(ASTContext &context) override {
     if (!Instance.getLangOpts().DelayedTemplateParsing)
       return;

-      std::set<FunctionDecl*> LateParsedDecls;
+      std::set<FunctionDecl *> LateParsedDecls;

On Tue, Jun 30, 2020 at 6:55 PM Matt Arsenault <arsenm2 at gmail.com>
wrote:
>
>
> On Jun 28, 2020, at 11:30, MyDeveloper Day via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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.
>
>
> My main issue with this would be that clang-format does things that I
> don’t believe are stated in the LLVM style guide and I also disagree with.
> There’s a whole set of cases where it makes unwelcome changes to put things
> that were on separate lines on a single line. Whenever I run clang-format,
> I typically git checkout -p to discard all of these.
>
> For example, it likes to take member initializer lists and pack them into
> as few lines as possible. This is just asking for merge conflicts (e.g.
> AMDGPUSubtarget has a ton of fields in it, and out of tree code is
> constantly adding new fields for unreleased subtargets). It also mangles
> BuildMI calls, where I believe every .add() should be on its own line, and
> stringing this into BuildMI().addFoo().addBar() is way less readable.
>
> I also believe it’s 4 space indent on line wraps differs from the stated 2
> space indent level (and this also disagrees with emacs llvm-style)
>
> -Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/9baa27f6/attachment.html>

> 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/20200630/09986695/attachment.html>

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>

On Tue, Jun 30, 2020 at 10:55 AM Matt Arsenault via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Jun 28, 2020, at 11:30, MyDeveloper Day via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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.
>
>
> My main issue with this would be that clang-format does things that I
> don’t believe are stated in the LLVM style guide and I also disagree with.
> There’s a whole set of cases where it makes unwelcome changes to put things
> that were on separate lines on a single line. Whenever I run clang-format,
> I typically git checkout -p to discard all of these.
>
> For example, it likes to take member initializer lists and pack them into
> as few lines as possible.
>
Note that this is solvable.  Put a comma at the end of your initializer
list, always.  This works for enums, array initializers, and AFAIK just
arbitrary cases of comma separated things between curly braces.  I
personally think that it's absolutely ridiculous that this "hack"
exists
and that there is no proper clang-format style option, but then again..  I
haven't proposed or contributed a fix, so I'm not exactly helping.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200630/c85770cf/attachment.html>

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>

In my experience clang-format helps avoiding spurious merge conflicts
when both parents are clang-formatted. For instance, one source made a
change (e.g. add an assert), undo it again, but a whitespace change
remains.

Another example was libclang, especially Index.h which up until
recently was not clang-formatted at all. It contains large enums. When
adding a value, `git clang-format` would re-format the entire enum,
mostly adding indentation to every line. The problem disappeared when
Index.h was clang-formatted.

Michael


Am Di., 30. Juni 2020 um 12:55 Uhr schrieb Matt Arsenault via llvm-dev
<llvm-dev at lists.llvm.org>:
>
>
>
> On Jun 28, 2020, at 11:30, MyDeveloper Day via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
> 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.
>
>
>
> My main issue with this would be that clang-format does things that I don’t
believe are stated in the LLVM style guide and I also disagree with. There’s a
whole set of cases where it makes unwelcome changes to put things that were on
separate lines on a single line. Whenever I run clang-format, I typically git
checkout -p to discard all of these.
>
> For example, it likes to take member initializer lists and pack them into
as few lines as possible. This is just asking for merge conflicts (e.g.
AMDGPUSubtarget has a ton of fields in it, and out of tree code is constantly
adding new fields for unreleased subtargets). It also mangles BuildMI calls,
where I believe every .add() should be on its own line, and stringing this into
BuildMI().addFoo().addBar() is way less readable.
>
> I also believe it’s 4 space indent on line wraps differs from the stated 2
space indent level (and this also disagrees with emacs llvm-style)
>
> -Matt
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev