Re: Replacing fixcc.py with clang-format?

[Jean Abou Samra]

Le 06/09/2022 à 20:56, Jonas Hahnfeld a écrit :
> On Tue, 2022-09-06 at 18:46 +0200, Jean Abou Samra wrote:
> > There's one thing I'd like to discuss now, for the reformatting round
> > before we do the branching.
> (Yes, I didn't manage yet to propose the reformatting. I'd like to do
> this after 2.23.13 is released. As a reminder, the idea is that we
> introduce a bit of churn before branching, but then don't get into
> trouble when backporting fixes to the branch.)
>
> > I would like to propose moving to clang-format as the canonical
> > formatting tool and removing fixcc.py. This will decrease our
> > maintenance burden. fixcc.py is more than 600 lines of code to
> > maintain.
> In general I'm not opposed. However, please note that clang-format is
> sometimes not stable over time, ie new versions can change formatting.
> Most projects use git-clang-format to incrementally format only the
> lines touched by commits. In LilyPond, the current practice is to
> format all code files, so we will experience this to its fullest. I
> don't know if that's going to be a problem, but I thought I'd mention
> it.




Interesting, I didn't know about this potential issue. To experiment,
I took clang-format 10 from 
https://github.com/muttleyxd/clang-tools-static-binaries,
tweaked the config file to remove options not understood with that
version, then applied it, committed, and applied clang-format 14
(the version I have from Fedora repositories) on top of that. The
size of the diff was

 47 files changed, 129 insertions(+), 75 deletions(-)

I didn't expect it, but I don't think it's too bad either. The fixcc
run for the latest stable release (87fedc2491) was around 350 changed
lines.

(The main difference between clang-format 10 and 14 seems to be that
clang-format 14 fixes places where the return type of a function
is not on its own lines, which is a good changes. There are also
some differences for operator methods.)



> > These days, git blame supports the --ignore-rev option, which makes
> > this less painful for future code historians.
> We can also have a .git-blame-ignore-revs in the repository. This
> already works on GitHub, and there is an open issue to also support it
> in GitLab: https://gitlab.com/gitlab-org/gitlab/-/issues/31423


Good idea!


> > It will obviously still produce merge conflicts with existing WIP branches.
> Usually branches can be "updated" by also running the (same) formatting
> tool on the changes, and then either git manages to resolve things
> itself or you can "port" the diff.


Yup.