I've seen a couple of request for extra Json formatting to match prettier capability.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D147003
Add configuration to specify macros.
Macros will be expanded, and the code will be parsed and annotated
in the expanded state. In a second step, the formatting decisions
in the annotated expanded code will be reconstructed onto the
original unexpanded macro call.
Eventually, this will allow to remove special-case code for
various macro options we accumulated over the years in favor of
one principled mechanism.
Differential Revision: https://reviews.llvm.org/D144170
For example, use 'Next' instead of 'Next != nullptr',
and '!Next' instead of 'Next == nullptr'.
Differential Revision: https://reviews.llvm.org/D144355
This reverts commit 879bfe6a979295f834b76df66b19a203b93eed0f.
owenpan@ pointed out on https://reviews.llvm.org/D140956 that this
actually makes the formatting more consistent, so it's not a regression.
This reverts commit a28f0747c2f3728bd8a6f64f7c8ba80b4e0cda9f.
It appears that this regresses some function definitions, added an
example as a comment over at https://reviews.llvm.org/D140956.
Previously committed in 46c94e5067b5 which was reverted in f0756e086010
due to a memory bug.
Closes#58949.
Differential Revision: https://reviews.llvm.org/D140543
Revert "[clang-format] Disable FixRanges in IntegerLiteralSeparatorTest"
Breaks buildbots, details in https://reviews.llvm.org/D140543
This reverts commit 879bd9146a2c9ea395abd7c1ebd0f76f414a4967.
This reverts commit 46c94e5067b5f396c24bb950505c79bc819bd4b8.
For the code-changing options InsertBraces, RemoveBracesLLVM, and
RemoveSemicolon, turn the option on only when running the token
analyzer pass for it. This improves the run-time and avoids
interference from other options.
Differential Revision: https://reviews.llvm.org/D140058
And make use of this from clangd's CodeComplete and IncludeFixer, although currently they are both restricted only to #include symbols.
Differential Revision: https://reviews.llvm.org/D128677
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This adds command-line flags to the tool:
+ -print: prints changed source code
+ -print=changes: prints headers added/removed
+ -edit: rewrites code in place
+ -insert=0/-remove=0: disables additions/deletions for the above
These are supported by a couple of new functions dumped into Analysis:
analyze() sits on top of walkUsed and makes used/unused decisions for
Includes. fixIncludes() applies those results to source code.
Differential Revision: https://reviews.llvm.org/D139013
If true, colons in ASM parameters will be placed after line breaks.
true:
asm volatile("string",
:
: val);
false:
asm volatile("string", : : val);
Differential Revision: https://reviews.llvm.org/D91950
I've:
- Sorted the members of FormatStyle alphabetical. The enums and structs
are kept close to the member.
- Sorted the yaml io functions, based on the type they operate on.
- Sorted the initializers in getLLVMStyle(), except that penalities are
kept at the end.
- Sorted the io of FormatStyle, this changes the --dump-config behavior.
- Moved the deprecated options into the only input case, this also
changes --dump-config, it does not put the not directly used options
in the .clang-format anymore.
- Sorted the comparisons in operator==.
- Added WhiteSpaceMacros in operator==, I've not actively looked if all
other members are compared.
- This showed flawed tests (or in my opinion a flawed io operation, but
that is another discussion and change).
Differential Revision: https://reviews.llvm.org/D137409
The token that records the number of closing braces to be inserted
may be on an unaffected line. Extra work is required in order to
actually insert the closing braces after inserting the matching
opening braces of affected lines.
Fixes#58161.
Differential Revision: https://reviews.llvm.org/D136437
Adds an option whether requires clause body should be aligned with
the `requires` keyword.
This option is now the default, both without configuration and in LLVM
style.
Fixes https://github.com/llvm/llvm-project/issues/56283
Differential Revision: https://reviews.llvm.org/D129443
Co-authored-by: Emilia Dreamer <emilia@rymiel.space>
Fixes: https://github.com/llvm/llvm-project/issues/58217
This change is to remove extraneous and unnecessary ';' from after a function definition, its off by default and carries the same "code modification" warning as some of our other code manipulating changes.
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D135466
Working in a mixed environment of both vscode/vim with a team configured prettier configuration, this can leave clang-format and prettier fighting each other over the formatting of arrays, both simple arrays of elements.
This review aims to add some "control knobs" to the Json formatting in clang-format to help align the two tools so they can be used interchangeably.
This will allow simply arrays `[1, 2, 3]` to remain on a single line but will break those arrays based on context within that array.
Happy to change the name of the option (this is the third name I tried)
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D133589
If the style wraps control statement braces, the opening braces
should be inserted after the trailing comments if present.
Fixes#57419.
Differential Revision: https://reviews.llvm.org/D132905
These statements are like switch statements in C, but without the 'case'
keyword in labels.
How labels are parsed. In UnwrappedLineParser, the program tries to
parse a statement every time it sees a colon. In TokenAnnotator, a
colon that isn't part of an expression is annotated as a label.
The token type `TT_GotoLabelColon` is added. We did not include Verilog
in the name because we thought we would eventually have to fix the
problem that case labels in C can't contain ternary conditional
expressions and we would use that token type.
The style is like below. Labels are on separate lines and indented by
default. The linked style guide also has examples where labels and the
corresponding statements are on the same lines. They are not supported
for now.
https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md
```
case (state_q)
StIdle:
state_d = StA;
StA: begin
state_d = StB;
end
endcase
```
Differential Revision: https://reviews.llvm.org/D128714
When removing an r_brace that is the first token of an annotated line, if the
line above ends with a line comment, clang-format generates invalid code by
merging the tokens after the r_brace into the line comment.
Fixes#56488.
Differential Revision: https://reviews.llvm.org/D129742
This patch mainly handles treating `begin` as block openers.
While and for statements will be handled in another patch.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D123450
Turn off RemoveBracesLLVM while analyzing InsertBraces and vice
versa to avoid potential interference of each other and better the
performance.
Differential Revision: https://reviews.llvm.org/D127685
If a closing brace is followed by a non-trailing comment, the
newline before the closing brace must also be removed.
Differential Revision: https://reviews.llvm.org/D125451
This reverts commit d46fa023caa2db5a9f1e21dd038bcb626261d958.
Regressed include order in some cases with trailing comments, see the
comments on https://reviews.llvm.org/D121370. Will add a regression test
in a follow-up commit.
