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

Tue Jun 30 13:26:09 PDT 2020

I'm very much in agreement here. I think that since the move to git the
"who is responsible for this change" especially with the couple of odd
commits that changed line endings is no longer particularly valid. We can
debate aspects of clang-format, but I think the general perspective of
moving to just clang formatting everything is probably a good idea.

-eric

On Tue, Jun 30, 2020 at 10:52 AM Chris Tetreault via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I literally just now resolved a massive merge conflict that resulted
> because a sweeping change was made to a switch, that then had to get
> clang-format'ed. My job would have been much simpler if that code was
> already formatted, but somebody got fancy with lining up everything in said
> switch. I assure you I had better things to do with that 30 minutes.
>
> clang-format is a great tool, specifically because using it means that
> nobody has to think about (or argue about) the formatting. But it works
> better if the code is already formatted. It would be nice if we could get
> to that point in a timely manner.
>
> -----Original Message-----
> From: Nicolai Hähnle <nhaehnle at gmail.com>
> Sent: Tuesday, June 30, 2020 10:18 AM
> To: Chris Tetreault <ctetreau at quicinc.com>
> Cc: MyDeveloper Day <mydeveloperday at gmail.com>; llvm-dev at lists.llvm.org
> Subject: [EXT] Re: [llvm-dev] [RFC] Semi-Automatic clang-format of files
> with low frequency
>
> 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.
> _______________________________________________
> 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/7fc781c8/attachment.html>