llvm dev - Aug 2021 - [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes

On Tue, Aug 10, 2021 at 13:13:09 +0200, Manuel Klimek via cfe-dev
wrote:
> clang-format is designed to run on changed lines, not to have all code be
> compliant. You can use it for the latter, but I think it's a pretty
> fundamental difference in development goals.
The problem I've seen is that the opinion of code formatted with 3 lines
of context can differ from 5 lines of context which can be still
different again given the entire file. The only reliable way we've
gotten it to work is to format the whole file every time. But we require
well-formatted code via CI processes, so that's fine (if one can afford
the "rewrite the world" every time the tool gets updated…hence why
some
projects are still on version 3.8(!), others 6, some even made it to 9).

--Ben

On Tue, Aug 10, 2021 at 1:32 PM Ben Boeckel <ben.boeckel at kitware.com>
wrote:
> On Tue, Aug 10, 2021 at 13:13:09 +0200, Manuel Klimek via cfe-dev wrote:
> > clang-format is designed to run on changed lines, not to have all code
be
> > compliant. You can use it for the latter, but I think it's a
pretty
> > fundamental difference in development goals.
>
> The problem I've seen is that the opinion of code formatted with 3
lines
> of context can differ from 5 lines of context which can be still
> different again given the entire file. The only reliable way we've
> gotten it to work is to format the whole file every time. But we require
> well-formatted code via CI processes, so that's fine (if one can afford
> the "rewrite the world" every time the tool gets updated…hence
why some
> projects are still on version 3.8(!), others 6, some even made it to 9).
>
The underlying design idea for clang-format is to give it the whole file as
*context*, but only *format* the changed lines.
clang-format supports that use case very well, and it can even be built
into presubmit checks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/876a3a61/attachment.html>

1) We don't change the defaults between versions
2) Any formatting changes caused between versions are either from
        a) bug fixes
        b) regressions

I'd like to think 2b) doesn't happen but we have to be realistic. It
does,
but it's why I don't like letting people change existing unit tests in a
review.

New features could potentially change things as we try to pick a new
default,

but mostly changes could be because clang-format miss identified a  correct
sequences of tokens (BinaryOperator vs PointerOrReference being a
particular pain point)

FWIW, I run a multi million line project, we run the bleeding edge, last
released version, each release of Clang-Format I have maybe 10-20 files to
change. If I left it 5 or so releases I'm sure the impact would seem
greater.

We check on CI and nightly builds (with -n option) and report out as
warnings so they get fixed pretty quickly.

If you are worried about git blame see (
https://akrabat.com/ignoring-revisions-with-git-blame/)

My 2c worth

MyDeveloperDay



On Tue, Aug 10, 2021 at 12:32 PM Ben Boeckel via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Tue, Aug 10, 2021 at 13:13:09 +0200, Manuel Klimek via cfe-dev wrote:
> > clang-format is designed to run on changed lines, not to have all code
be
> > compliant. You can use it for the latter, but I think it's a
pretty
> > fundamental difference in development goals.
>
> The problem I've seen is that the opinion of code formatted with 3
lines
> of context can differ from 5 lines of context which can be still
> different again given the entire file. The only reliable way we've
> gotten it to work is to format the whole file every time. But we require
> well-formatted code via CI processes, so that's fine (if one can afford
> the "rewrite the world" every time the tool gets updated…hence
why some
> projects are still on version 3.8(!), others 6, some even made it to 9).
>
> --Ben
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/5086d9f5/attachment.html>