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.
Details
Diff Detail
Event Timeline
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
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
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
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
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.
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
That's nice, I've subscribed to the clang-format tag.
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?
@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
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.