[llvm-dev] [RFC] Semi-Automatic clang-format of files with low frequency (original) (raw)

Michael Kruse via llvm-dev llvm-dev at lists.llvm.org
Wed Jul 1 10:22:55 PDT 2020

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

More information about the llvm-dev mailing list