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

[Hal Finkel via llvm-dev]

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
> 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/738df1ca/attachment-0001.html>