[clang-format] NFC ensure Style operator== remains sorted for ease of editing

[MyDeveloperDay]

Summary

D144170: [clang-format] Add simple macro replacements in formatting. didn't go via the normal clang-format reviewers and we'd have pointed out that this list of options remains sorted.

[rymiel]

didn't go via the normal clang-format reviewers

Is there a reason for this? This isn't the only case either, for example:
https://reviews.llvm.org/D143070 https://reviews.llvm.org/D144170 https://reviews.llvm.org/D88299 https://reviews.llvm.org/D135356

I don't have a lot of experience here, so maybe I'm missing "historical" context, but this confuses me a lot...

[MyDeveloperDay]

In D147176#4231952, @rymiel wrote:

didn't go via the normal clang-format reviewers

Is there a reason for this? This isn't the only case either, for example:
https://reviews.llvm.org/D143070 https://reviews.llvm.org/D144170 https://reviews.llvm.org/D88299 https://reviews.llvm.org/D135356

I don't have a lot of experience here, so maybe I'm missing "historical" context, but this confuses me a lot...

@klimek was one of the original clang-format creators, and @sammccall I believe works on clangd among many other things, which might well be consuming libFormat.

Honestly these developers are pretty much 'OGs' , I'm happy to tidy up after them if they don't quite follow our current conventions. Obviously at any point you can add yourself to a review and add the appropriate tags.

Phabractor does support automatically assigned code reviewers via the "Owners" package, and via Herald rules. I could see if I can add one to at least auto assign the clang-format tag, that should bring it onto our radar

H987 Clang Format, Tags and Reviewers

[MyDeveloperDay]

I can auto add us as all as reviewers if you'd like? This means if the title contains [clang-format] or it impacts a file path of /clang/lib/Format it should in theory run this rule

[MyDeveloperDay]

Also I've added a couple of other rules

This should in theory, automatically add a comment to a clang-format review that contains a Format.h change but not a ClangFormatStyleOption.rst change and vice versa

(as it just did below)....

Your review contains a change to clang/include/clang/Format/Format.h but does not contain an update to ClangFormatStyleOptions.rst

ClangFormatStyleOptions.rst is generated via clang/docs/tools/dump_format_style.py, please run this to regenerate the .rst

You can validate that the rst is valid by running.

./docs/tools/dump_format_style.py
@mkdir -p html
/usr/bin/sphinx-build -n ./docs ./html

[MyDeveloperDay]

This comment was removed by MyDeveloperDay.

[klimek]

I apologize for not tagging appropriately - is that process documented somewhere?

NOTE: Clang-Format Team Automated Review Comment

It looks like your clang-format review does not contain any unit tests, please try to ensure all code changes have a unit test (unless this is an NFC or refactoring, adding documentation etc..)

Add you unit tests in clang/unittests/Format and build ninja FormatTests we recommend using the verifyFormat(xxx) format of unit tests rather than EXPECT_EQ as this will ensure you change is tolerant to random whitespace changes (see FormatTest.cpp as an example)

For situations where your change is altering the TokenAnnotator.cpp which can happen if you are trying to improve the annotation phase to ensure we are correctly identifying the type of a token, please add a token annotator test in TokenAnnotatorTest.cpp

[klimek]

And thanks a lot for cleaning up, really appreciate it!

[MyDeveloperDay]

In D147176#4232808, @klimek wrote:

I apologize for not tagging appropriately - is that process documented somewhere?

I've implemented it via Phabricator Herald rules now, so we should be good going forward, @klimek you get a free pass as far as I'm concerns, I'll always be happy to tidy up after you given the opportunity you gave me in the past.

[HazardyKnusperkeks]

In D147176#4232633, @MyDeveloperDay wrote:

Honestly these developers are pretty much 'OGs' , I'm happy to tidy up after them if they don't quite follow our current conventions. Obviously at any point you can add yourself to a review and add the appropriate tags.

Would you also please be so kind to sort the parsing function? I have currently no working clang-format development setup because of a change of hardware.

Phabractor does support automatically assigned code reviewers via the "Owners" package, and via Herald rules. I could see if I can add one to at least auto assign the clang-format tag, that should bring it onto our radar

H987 Clang Format, Tags and Reviewers

That's nice, I've subscribed to the clang-format tag.

[owenpan]

In D147176#4232702, @MyDeveloperDay wrote:

I can auto add us as all as reviewers if you'd like? This means if the title contains [clang-format] or it impacts a file path of /clang/lib/Format it should in theory run this rule

You can add me to the reviewers. Can you add clang/tools/clang-format (and fuzzer if not recursive) to the paths? Should we also add clang/unittests/Format?

[owenpan]

@MyDeveloperDay We keep getting "spammed" by [libc++][format] patches. Can you delete the rule in H987:

"field": "differential.revision.title",
"condition": "contains",
"value": "[Format]"

or change "contains" to something equivalent to "starts with"?

[MyDeveloperDay]

In D147176#4263621, @owenpan wrote:

@MyDeveloperDay We keep getting "spammed" by [libc++][format] patches. Can you delete the rule in H987:

"field": "differential.revision.title",
"condition": "contains",
"value": "[Format]"

or change "contains" to something equivalent to "starts with"?

I removed this a few days ago, we should be good, I think that review has clang-format on it.. one sec let me remove us

[MyDeveloperDay]

we should be good now

[owenpan]

In D147176#4265130, @MyDeveloperDay wrote:

we should be good now

Thanks! I really like these new rules!

[MyDeveloperDay]

In D147176#4266496, @owenpan wrote:

In D147176#4265130, @MyDeveloperDay wrote:

we should be good now

Thanks! I really like these new rules!

Yeah sorry for the Spam, I'm hoping this prevent stuff coming in under the radar, but also so we can keep an eye on what's coming in.

clang/include/clang/Format/Format.h

return AccessModifierOffset == R.AccessModifierOffset &&
            JavaImportGroups == R.JavaImportGroups &&
            JavaScriptQuotes == R.JavaScriptQuotes &&
            JavaScriptWrapImports == R.JavaScriptWrapImports &&
            KeepEmptyLinesAtTheStartOfBlocks ==
                R.KeepEmptyLinesAtTheStartOfBlocks &&
            Language == R.Language &&
            LambdaBodyIndentation == R.LambdaBodyIndentation &&
            LineEnding == R.LineEnding && MacroBlockBegin == R.MacroBlockBegin &&
-           MacroBlockEnd == R.MacroBlockEnd &&
+           MacroBlockEnd == R.MacroBlockEnd && Macros == R.Macros &&
            MaxEmptyLinesToKeep == R.MaxEmptyLinesToKeep &&
            NamespaceIndentation == R.NamespaceIndentation &&
            NamespaceMacros == R.NamespaceMacros &&
            ObjCBinPackProtocolList == R.ObjCBinPackProtocolList &&
            ObjCBlockIndentWidth == R.ObjCBlockIndentWidth &&
            ObjCBreakBeforeNestedBlockParam ==
                R.ObjCBreakBeforeNestedBlockParam &&
            ObjCSpaceAfterProperty == R.ObjCSpaceAfterProperty &&
return AccessModifierOffset == R.AccessModifierOffset &&
            SpacesInLineCommentPrefix.Maximum ==
                R.SpacesInLineCommentPrefix.Maximum &&
            SpacesInParentheses == R.SpacesInParentheses &&
            SpacesInSquareBrackets == R.SpacesInSquareBrackets &&
            Standard == R.Standard &&
            StatementAttributeLikeMacros == R.StatementAttributeLikeMacros &&
            StatementMacros == R.StatementMacros && TabWidth == R.TabWidth &&
            TypenameMacros == R.TypenameMacros && UseTab == R.UseTab &&
-           WhitespaceSensitiveMacros == R.WhitespaceSensitiveMacros &&
-           Macros == R.Macros;
+           WhitespaceSensitiveMacros == R.WhitespaceSensitiveMacros;
   }
 
   std::optional<FormatStyle> GetLanguageStyle(LanguageKind Language) const;
 
   // Stores per-language styles. A FormatStyle instance inside has an empty
   // StyleSet. A FormatStyle instance returned by the Get method has its
   // StyleSet set to a copy of the originating StyleSet, effectively keeping the
   // internal representation of that StyleSet alive.