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
Adds the support for tokens that have forms like unary operators.
- bang operators: `!name`
- cond operator: `!cond`
- numeric literals: `+1`, `-1`
cond operator are one of bang operators but is distinguished because it has very specific syntax.
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>
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
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 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.
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`.
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
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.
Function and variable names are not detected when there is a
__attribute__((x)) preceding the name.
Fixes#64137.
Differential Revision: https://reviews.llvm.org/D156370
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>
There are two parts to this fix:
- Annotate the paren after an AttributeMacro as an AttributeLParen.
- Treat an AttributeMacro-without-paren the same as one with a paren.
I added a new test-case to differentiate a macro that is or is-not an
AttributeMacro; also handled whether ColumnLimit is set to infinite (0) or a
finite value, as part of this patch is in ContinuationIndenter.
Closes#68722.
Differential Revision: https://reviews.llvm.org/D145262
There are two parts to this fix:
- Annotate the paren after an AttributeMacro as an AttributeLParen.
- Treat an AttributeMacro-without-paren the same as one with a paren.
I added a new test-case to differentiate a macro that is or is-not an
AttributeMacro; also handled whether ColumnLimit is set to infinite (0) or a
finite value, as part of this patch is in ContinuationIndenter.
Closes#68722.
Differential Revision: https://reviews.llvm.org/D145262
