This implements the annotation of the values in TableGen.
The main changes are,
- parseTableGenValue(), the simplified parser method for the syntax of
values.
- modified consumeToken() to parseTableGenValue in 'if', 'assert' and
after '='.
- modified parseParens() to call parseTableGenValue inside.
- modified parseSquare() to to call parseTableGenValue inside, with
skipping separator tokens.
- modified parseAngle() to call parseTableGenValue inside, with skipping
separator tokens.
If clang-format is not sure whether a `requires` keyword starts a
requires clause or a requires expression, it looks ahead to see if any
token disqualifies it from being a requires clause. Among these tokens
was `decltype`, since it fell through the switch.
This patch allows decltype to exist in a require clause.
I'm not 100% sure this change won't have repercussions, but that just
means we need more test coverage!
Fixes https://github.com/llvm/llvm-project/issues/78645
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>
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.
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[];
};
```
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.
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
Pull request #65409 changed the brace kind heuristic to not treat a
preprocessor if directive as a in statement, however, this caused some
regressions.
If the contents of a brace don't immediately determine the brace kind,
the heuristic will look at the characters immediately before and after
the closing brace to determine the brace type.
Unfortunately, if the closing brace was preceded by a preprocessor
directive, for example `#endif`, the preceding token was `endif`, seen
as just an identifier, so the braces were understood as a braced list.
This patch fixes this behaviour by skipping all preprocessor directives
when calculating brace types. Comments were already being skipped, so
now preprocessor lines are skipped alongside comments.
Fixes https://github.com/llvm/llvm-project/issues/68404
Previously, upon encountering an equals sign while parsing a lambda in
the UnwrappedLineParser, it would fall through and fail. This caused any
lambda template with a default argument for a template parameter to be
annotated as an ArraySubscriptLSquare.
This patch allows equals signs in the UnwrappedLineParser if we're
currently in a template parameter list. This resolved a FIXME that was
in the lambda parsing function.
This patch seems deceptively easy, it's likely it doesn't solve the
FIXME entirely, or causes other issues (the FIXME itself mentions
something about Objective-C, which I cannot comment about). However this
patch is sufficient to fix the below issue.
Fixes https://github.com/llvm/llvm-project/issues/68913
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Don't remove the outermost parentheses surrounding a return statement
expression when inside a function/lambda that has the decltype(auto)
return type.
Fixed#67892.
clang-format uses a heuristic to determine if a requires() is either a
requires clause or requires expression, based on what is in the
parentheses. Part of this heuristic assumed that a requires clause can
never contain a comma, however this is not the case if said comma is in
the template argument of a type.
This patch allows commas to appear in a requires clause if an angle
bracket `<` has been opened.
Fixes https://github.com/llvm/llvm-project/issues/65904
When encountering braces, such as those of a designated initializer,
clang-format scans ahead to see what is contained within the braces. If
it found a statement, like an if-statement of for-loop, it would deem
the braces as not an initializer, but as a block instead.
However, this heuristic incorrectly included a preprocessor `#if` line
as an if-statement. This manifested in strange results and discrepancies
between `#ifdef` and `#if defined`.
With this patch, `if` is now ignored if it is preceeded by `#`.
Fixes most of https://github.com/llvm/llvm-project/issues/56685
The ObjC-block detection code only supports a single token as the return type. Add support to detect pointers, too (ObjC has lots of object-pointers).
For example, using `BasedOnStyle: WebKit`, the following is stable output:
```
int* p = ^int*(void)
{ //
return nullptr;
}
();
```
After the patch, this is stable:
```
int* p = ^int*(void) { //
return nullptr;
}();
```
Differential Review: https://reviews.llvm.org/D146434
Remove the double check, move the comment.
This changes behavior, but I think for the better. Despite the comment
my personal opinion would be to not even gracefully handle the one
semicolon, it shouldn't be there.
Differential Revision: https://reviews.llvm.org/D138373
When parsing a requires clause, the UnwrappedLineParser would delegate to
parseParens with an AmpAmpTokenType set to BinaryOperator. However,
parseParens would not carry this over into any nested parens, meaning it
could assign a different token type to an && in a requires clause.
This patch makes sure parseParens inherits its parameter when performing
a recursive call.
Fixes https://github.com/llvm/llvm-project/issues/63251
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D153641
This is a retry of https://reviews.llvm.org/D114583, which was backed
out for regressions.
Clang Format is detecting a nested scope followed by another open brace
as a braced initializer list due to incorrectly thinking it's matching a
braced initializer at the end of a constructor initializer list which is
followed by the body open brace.
Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so
it's not super straightforward to distinguish these cases given the
current structure of calculateBraceTypes. My current hypothesis is that
these can be disambiguated by looking at the token preceding the
l_brace, as initializer list parameters will be preceded by an
identifier, but a scope block generally will not (barring the MACRO
wildcard).
To this end, I am adding tracking of the previous token to the LBraceStack
to help scope this particular case.
TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452.
Fixes#33891.
Fixes#52911.
Differential Revision: https://reviews.llvm.org/D150403
out for regressions.
Clang Format is detecting a nested scope followed by another open brace
as a braced initializer list due to incorrectly thinking it's matching a
braced initializer at the end of a constructor initializer list which is
followed by the body open brace.
Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so
it's not super straightforward to distinguish these cases given the
current structure of calculateBraceTypes. My current hypothesis is that
these can be disambiguated by looking at the token preceding the
l_brace, as initializer list parameters will be preceded by an
identifier, but a scope block generally will not (barring the MACRO
wildcard).
To this end, I am adding tracking of the previous token to the LBraceStack
to help scope this particular case.
TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452.
Fixes#33891.
Fixes#52911.
Differential Revision: https://reviews.llvm.org/D150403
Before:
```
module x
#( //
parameter x)
( //
input y);
endmodule
```
After:
```
module x
#(//
parameter x)
(//
input y);
endmodule
```
If the first line in a port or parameter list is not a comment, the
following lines will be aligned to the first line as intended:
```
module x
#(parameter x1,
parameter x2)
(input y,
input y2);
endmodule
```
Previously, the indentation would be changed to an extra continuation
indentation relative to the start of the parenthesis or the hash if
the first token inside the parentheses was a comment. It is a feature
introduced in ddaa9be97839. The feature enabled one to insert a `//`
comment right after an opening parentheses to put the function
arguments on a new line with a small indentation regardless of how
long the function name is, like this:
```
someFunction(anotherFunction( // Force break.
parameter));
```
People are unlikely to use this feature in a Verilog port list because
the formatter already puts the port list on its own lines. A comment
at the start of a port list is probably a comment for the port on the
next line.
We also removed the space before the comment so that its indentation
would be same as that for a line comment anywhere else in the port
list.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D149562
Contributed by @jankuehle!
Users can choose to only import/export the type of the symbol (not value nor namespace) by adding a `type` keyword, e.g.:
```
import type {x} from 'y';
import {type x} from 'y';
export type {x};
export {type x};
```
Previously, this was not handled and would:
- Terminate import sorting
- Remove the space before the curly bracket in `export type {`
With this change, both formatting and import sorting work as expected.
Reviewed By: MyDeveloperDay, krasimir
Differential Revision: https://reviews.llvm.org/D150116
There doesn't seem to be an issue on GitHub. But previously, a space
would be inserted before the goto colon in the code below.
switch (x) {
case 0:
goto_0: {
action();
break;
}
}
Previously, the colon following a goto label would be annotated as
`TT_InheritanceColon`. A goto label followed by an opening brace
wasn't recognized. It is easy to add another line to have
`spaceRequiredBefore` function recognize the case, but I believed it
is more proper to avoid doing the same thing in `UnwrappedLineParser`
and `TokenAnnotator`. So now the label colons would be labeled in
`UnwrappedLineParser`, and `spaceRequiredBefore` would rely on that.
Previously we had the type `TT_GotoLabelColon` intended for both goto
labels and case labels. But since handling of goto labels and case
labels differ somewhat, I split it into separate types for goto and
case labels.
This patch doesn't change the behavior for case labels. I added the
lines annotating case labels because they would previously be
mistakenly annotated as `TT_InheritanceColon` just like goto labels.
And since I added the annotations, the checks for the `case` and
`default` keywords in `spaceRequiredBefore` are not necessary anymore.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D148484
