This diff adds a new option SpacesAroundConditions that inserts spaces inside the braces for conditional statements. It's used by the Zeek project (https://github.com/zeek/zeek) as described in their style guide (https://github.com/zeek/zeek-docs/blob/master/devel/style_guide.rst#conditional-expressions)
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 38900 Build 38899: arc lint + arc unit
Event Timeline
clang/include/clang/Format/Format.h | ||
---|---|---|
1950 | its position in the file and the documentation is not quite alphabetic, given you are close i'd make it so | |
2088 | move upto just before SpacesBeforeTrailingComments | |
clang/lib/Format/Format.cpp | ||
520 | Same here | |
779 | Sorry move to line 771-772 | |
clang/lib/Format/TokenAnnotator.cpp | ||
2509 | this isn't really the normal naming convention for variables, I think it would be IsCondKw I think its clearer without using abbreviations, why not just make this a function? does the Lambda really give us anything here in such a big function other than clutter? static bool isConditionKeyword(....) | |
2919 | I'm not sure I understand this change so you added a tok::l_paren here? but its not just for your style, so something else must have changed. Did you run all FormatTests? one of the tests you add need to test why you added this here |
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2290 | SpacesInConditionalStatement is probably a better name, remaining consistent with existing SpacesIn* options, as well as indicating it only affects the entire conditional statement, and not individual conditions within the statement. | |
clang/lib/Format/TokenAnnotator.cpp | ||
2511 | It seems that you are mixing statement tokens if, while, etc. with preprocessor and macro tokens. Going by the documentation, this is unexpected. | |
2919 | This is not covered by your tests. |
Changed option name to SpacesInConditionalStatement, added isKeywordWithCondition method, added some extra tests
Sorry for the delay on getting back to this. I'm not the original author and I was waiting for changes from him, and then I slacked on getting them submitted.
clang/include/clang/Format/Format.h | ||
---|---|---|
1955 | Nitpick: this option is still not in alphabetical order. Please re-order it. Otherwise, this looks good to me. |
Thank you for the patch.
If you plan to continue to submit patches I think it would be worthwhile if you applied for commit access, This is not the first revision from you and we need more people who are willing to help with clang-format to fix bugs and do code reviews of other peoples work.
You clearly have an interested and an understanding of how clang-format works and a desire to help make it EVEN better. It is also good to get access in order to maintain the work you do,
As the cut over to github I believe is tomorrow at the LLVM meeting it might be worth waiting until after that point to work out what the procedure to obtain access will be as I'm unclear if getting permission will be the same as outlined here
https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access
Thanks for the consideration on committer access, but I'm going to have to pass for the time being.
That said, can someone land this patch?
clang/unittests/Format/FormatTest.cpp | ||
---|---|---|
14382 | show "else if" example |
clang/unittests/Format/FormatTest.cpp | ||
---|---|---|
14386 | is this what you expect? or should it be while ( ( a && b ) ) |
SpacesInConditionalStatement is probably a better name, remaining consistent with existing SpacesIn* options, as well as indicating it only affects the entire conditional statement, and not individual conditions within the statement.