clang-format has logic to align declarations of multiple variables of
the same type, aligning them at the equals sign. This logic is applied
in for loops as well. However, this alignment logic also erroneously
affected the equals signs of designated initializers.
This patch forbids alignment if the token 2 tokens back from the equals
sign is a designated initializer period.
Fixes https://github.com/llvm/llvm-project/issues/73902
Make TableGen's statements to be parsed considering their structure.
- Avoid to parse label
- Avoid class from being parsed as c++'s class
- Support if statement of the form `if <cond> then { ... }`
- Support defset statement of the form `defset <type> <name> {}`
---------
Co-authored-by: Björn Schäpers <github@hazardy.de>
Fixesllvm/llvm-project#62904
`AlignArrayOfStructures: Left` combined with `SpacesInParentheses: true`
causes the first cell of every row to have 1 additional space.
We were only setting the first cell of the first row to be against the
left brace, now every row will be against the left brace.
This addresses a problem with formatting attributes. Some context:
- eaff083035c8 changed `isStartOfName` to fix problems inside
`#pragma`s, but this behavior changed formatting of attribute macros in
an undesirable way.
- efeb546865c233dfa7706ee0316c676de9f69897 changed Google format style
to fix some widely used attributes.
Instead of changing the format style, this commit specializes behavior
introduced in eaff083035c8 to `#pragma`s. This seems to work well in
both cases.
Also update the test with two `GUARDED_BY` directives. While the
formatting after efeb546865c233dfa7706ee0316c676de9f69897 seems better,
this case is rare enough to not warrant the extra complexity. We are
reverting it back to the state it had before
efeb546865c233dfa7706ee0316c676de9f69897.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Some unwrapped lines are marked as continuations of the previous lines,
for example the ports in a Verilog module header. Previously, if the
first line following the ports line was changed, and git-clang-format
was run, the changed line would be indented by an extra continuation
indentation.
Done as requested in llvm/llvm-project#77045
I have changed the test a bit, because since the root problem was fixed,
the original test would possibly never crash.
clang-format performs a heuristic to see if a right parenthesis is the
parenthesis of a cast expression. This check never looked ahead to see
if the next token is an ampamp && token. This resulted in the paren
being set as an CastRParen, and the following ampamp got annotated as an
UnaryOperator!
Since && can never be a unary operator is standard C++, this patch
forbids the right paren from ever becoming a cast.
Fixes https://github.com/llvm/llvm-project/issues/77680
1. There are multiple calls to addFakeParenthesis; move the guard to not
assign fake parenthesis into the function to make sure we cover all
calls.
2. MustBreakBefore can be set on a token in two cases: either during
unwrapped line parsing, or later, during token annotation. We must
keep the latter, but reset the former.
3. Added a test to document that the intended behavior of preferring not
to break between a return type and a function identifier.
For example, with MOCK_METHOD(r, n, a)=r n a, the code
MOCK_METHOD(void, f, (int a, int b)) should prefer the same breaks as
the expanded void f(int a, int b).
Fixesllvm/llvm-project#76716
Fixes parsing of `[0]{}`. Before this patch it was begin parsed as a
lambda, now it is correctly parsed as a designator initializer.
Function pointers are detected as a type of declaration using
FunctionTypeLParen. They are aligned based on rules for
AlignConsecutiveDeclarations. When a function pointer is on the
right-hand side of an assignment, the alignment of the function pointer
can result in excessive whitespace padding due to the ordering of
alignment, as the alignment processes a line from left-to-right and
first aligns the declarations before and after the assignment operator,
and then aligns the assignment operator. Injection of whitespace by
alignment of declarations after the equal sign followed by alignment of
the equal sign results in the excessive whitespace.
Fixes#68079.
If there are possible column formats, but they weren't selected because
they don't fit within remaining characters for the current path then
applying severe penalty to induce column layout by selection of a
different path seems fair.
But if due to style configuration or what the input code is, there are
no possible column formats, different paths aren't going to have column
layouts. Seems wrong to apply the severe penalty to induce column
layouts if there are none available.
It just causes selection of sub-optimal paths, e.g. get bad formatting
when brace initializers are used inside lambda bodies.
Fixes#56350
The current CI doesn't use the latest clang-format and fails most
clang-format patches on the code formatting check. This patch
temporarily removes the clang-format style from the .clang-format
files.
This restores a subset of functionality that was forego in
d68826dfbd987377ef6771d40c1d984f09ee3b9e.
Streaming multiple string literals is rare enough in practice, hence
that change makes sense in general. But it seems people were
incidentally relying on this for having line breaks after string
literals that ended with `\n`.
This patch tries to restore that behavior to prevent regressions in the
upcoming LLVM release, until we can implement some configuration based
approach as proposed in https://github.com/llvm/llvm-project/pull/69859.
We have found that 199fc973ced20016b04ba540cf63a1d4914fa513 regresses
formatting of our codebases because we do not properly configure the
names of attribute macros.
`GUARDED_BY` and `ABSL_GUARDED_BY` are very commoon in Google codebases
so it is reasonable to include them by default to avoid the need for
extra configuration in every Google repository.
This regressions was introduced in
70d7ea0cebcf363cd0ddcfb76375fb5fada87dd5.
The commit moved some code and correctly picked up an explicit check for
not running on Verilog.
However, the moved code also never ran for JavaScript and after the
commit we run it there and
this causes the wrong formatting of:
```js
export type Params = Config&{
columns: Column[];
};
```
into
```js
export type Params = Config&{
columns:
Column[];
};
```
Fixes#74876.
During the parsing of `operator<(Foo&) {}`, there was no handling for
the operator<, so it called `consumeToken()` again, causing the
`AnnotationParser::Scopes` to have one additional left brace each time
it tried to parse it, leaving it unbalanced.
Because of this, in the following code:
```cpp
class Foo {
void operator<(Foo&) {}
Foo& f;
};
```
The `&` in the reference member, was being interpreted as
`TT_BinaryOperator` instead of `TT_PointerOrReference`.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
In a tagged union expression, there should be a space between the field
name and the data. Previously, the tag could be recognized as part of a
dotted identifier or a struct literal, and the space would be omitted.
Add a style option to specify the order that property attributes should
appear in ObjC property declarations (property attributes are things like
`nonatomic, strong, nullable`).
Closes#71323.
Differential Revision: https://reviews.llvm.org/D150083
PR #69473 introduced skipping PP directives when determining the brace
kind of an lbrace. However, it did so by skipping to the end of the line
when encountering a hash character. This means it also skipped to the
end of line when encountering a macro stringizing operator, which,
unlike PP directives, don't have effect until the end of line.
This led to cases where the rbrace could be completely skipped if it was
on the same line as a stringizing operator.
This patch skips hash characters if we're already in a PP directive, as
you can't define a macro inside of a macro
Fixes https://github.com/llvm/llvm-project/issues/72662
This would also fix the overlapping replacements below:
```
$ clang-format
a(
#else
#endif
) = []() {
)}
The new replacement overlaps with an existing replacement.
New replacement: <stdin>: 38:+7:"
"
Existing replacement: <stdin>: 38:+7:" "
```
Fixed#73487.
If a line contains a comment outside of (fake) parentheses, the part
following it is indented according to `CurrentState.Indent`. A Verilog
case label and the statement that follows are broken with
mustBreakBefore. So the part that follows the case label needs some
special handling. Previously, that variable was left out. So the
indentation was wrong when there was a comment.
old:
```Verilog
case (data)
16'd0:
result = //
10'b0111111111;
endcase
case (data)
16'd0:
//
//
result = //
10'b0111111111;
endcase
```
new:
```Verilog
case (data)
16'd0:
result = //
10'b0111111111;
endcase
case (data)
16'd0:
//
//
result = //
10'b0111111111;
endcase
```
The Verilog implication operator `->` is a binary operator meaning
either the left hand side is false or the right hand side is true.
Previously it was treated as the C++ struct member operator.
I didn't even know it existed when I added the operator formatting part.
And I didn't check all the tests for all the operators I added. That is
how the bad test got in.
