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

[Chris Tetreault via llvm-dev]

At my previous workplace, we had a codebase that was 100% completely formatted via clang-format. I had a coworker that *hated* the local style. However, since we had complete coverage, he was able to set up git hooks to run clang-format to reformat the codebase to his preferred style on checkout and back on commit. He was only able to do this because the coverage was complete.

This doesn’t help with the merge conflict issue, but it definitely helps with the “clang-format does this thing that I don’t like” issue. However, until we finish formatting the codebase, nobody can do this.

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Hal Finkel via llvm-dev
Sent: Tuesday, June 30, 2020 11:12 AM
To: Matt Arsenault <arsenm2 at gmail.com>; MyDeveloper Day <mydeveloperday at gmail.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] [RFC] Semi-Automatic clang-format of files with low frequency



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<mailto: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/ea2e6cec/attachment.html>