I don't think we should change the LLVM style

this LGTM

can you clang-format so it passes the pre-merge checks

LGTM thank you for trying where you could to use verifyFormat

This LGTM, thank you.

I'd be quite interested to understand what the impact (if any) would be on javascript and C# formatting

A quick search of github shows over 1 billion hits to the word struct, in a variety of flavours, I'm just not convinced we want a separate option for each and every case,

In D99031#2640654, @HazardyKnusperkeks wrote:

In D99031#2640425, @aybassiouny wrote:

How about verifyFormat? Would that fail without your patch?

@HazardyKnusperkeks sorry, but not sure that I understand your point. Are you suggesting to use verifyFormat in my UT instead of EXPECT_EQ?

I'm pretty sure @MyDeveloperDay would ask for that. I would maybe use both. But what it really interesting for me if verifyFormat would fail, i.e. would clang-format misformat something previously correctly formatted.

If you follow people tweeting about clang-format (as I do) and you look through the bug tracking system, one major criticism of clang-format is that the second clang-format can be different from the first, sometimes an equilibrium can be found sometimes not.

I've seen this before maybe with regard to something else, but can't quite recall. (maybe a bug in the bug tracker)

could you please mark your comments done when they are done.

Just out of interest and we are supposed to ask for this but can you point to public style guide that uses this style. (actually I don't mind if other formatting tools have this capability and you highlight it, like astyle or editorConfig etc)

+1 we are not going to land this with a failing or removed test

LGTM

LGTM

I think I'd be concern about the <string.h> case (lets ignore the fact that I should be including <string>

LGTM, we need to run this on a large code base to ensure it doesn't make mistakes in real code, but I think this looks good.

the LGTM, please mark your comments as done when done.

I'm just going to say this here, but LLVM doesn't like the use of braces on single lines (I don't actually like that myself, but I go with the convention when I remember),

I guess I'm not making myself clear, I was just hoping you could be super explicit about what you are changing so anyone coming into this review would understand why the behaviour had changed (this is just pseudo code it may not be correct for all cases, but you should get the idea), We need to cover the SBS_Empty,SBS_Always,SBS_Never cases and the ShortLoops true/false

I'm never going to be the one to accept patches where people change tests without making it really clear why they are changing it. You have to prove you are not regressing behaviour, I work on the Beyonce rule, "if you liked it you should have put a test on it"

If it's a drop in replacement (does everything clang-format does and more), what's the benefit for that cost?

What can be done to move this change along?

I wonder if we should consider suggesting a different type of tool for clang

I have a script that runs clang-format -n on various directories in clang
that are clang format clean, polly is one of them because they have clang
format as a unit test

My advice leave it out of the release, the next release comes round pretty quickly. This gives us 6 months of people who use the snapshots to iron out any issues.

I like this much better LGTM

This needs a unit test, I personally don't understand what this is doing or why its needed, if its a bug can you reference a bug in bugzilla that explains the bug a little clearer please

LGTM

LGTM I think, it would be good to get input from other reviewers

I think this is one of those reviews that ultimately I think would be useful if we could ensure it works 100% correctly, but I think it goes against the original ethos of clang-format and I think if @djasper or @klimek the original authors were here they'd probably push back.

Thanks for explaining! I visited the his profile. It is really confusing.

In D94891#2505736, @ChuanqiXu wrote:

@231084fg may I ask why you remove the reviews for the patch?

Similarly I see users having to define everything just to turn one thing off

I think this is LGTM, however..

What I can't easily tell from the tests is if you are overriding any styles defined in the parent with a local style.

I think the revision whilst it does what is needed to structs doesn't address the many other times this forms appear. I think we need something a little more extensive. It can't just be when a line starts with struct

Please address the "not done" comment (regarding the sorting), but other than that its LGTM

Sorry but due to the following issue raised by @RatTac , I'm reverting this prior to the LLVM 12 branch out so I can work on it further.

Thank you for changing the dump_style to make this clearer

Thie LGTM, just to check a few nits

My assumption is that you want to stick with the minimum and maximum is that correct?

I think I would remove the code examples from the "AlignConsecutive style" to avoid confusion (that would be the first change)

LGTM

This LGTM

@RatTac Would you please consider copying the comment onto the review D92753: [clang-format] Add IndentPragma style to eliminate common clang-format off scenario and not the commit, I have a reply but don't want to write it here.

Thank you for submitting this patch?

This LGTM, I'm not sure if others have any further comments