Reverts commit d68826dfbd98, which changes the previous default behavior
of always breaking before a stream insertion operator `<<` if both
operands are string literals.
Also reverts the related commits 27f547968cce and bf05be5b87fc.
See the discussion in #88483.
This adds an option to break function definition parameters, putting
them on the next line after the function's opening paren.
This was a missing step towards allowing styles which require all
function definition parameters be on their own lines.
Closes#62963
This reverts commit b92d6dd704d789240685a336ad8b25a9f381b4cc. See
github.com/llvm/llvm-project/commit/b92d6dd704d7#commitcomment-139992444
We should use a tool like Visual Studio to clean up the headers.
This resolves an issue in clang-format where `new` and `delete` were
incorrectly formatted as keywords in C files. The fix modifies
`TokenAnnotator::spaceRequiredBetween` to handle `new` and `delete` when
used as identifiers for function pointers in structs in C code.
llvm-project/clang/lib/Format/TokenAnnotator.cpp:2707:43:
error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
auto IsQualifiedPointerOrReference = [this](FormatToken *T) {
^~~~
1 error generated.
The while loop on line 3814 can cause a segmentation fault getting the
Next field on a nullptr. This is because further down, on line 3823,
there is another for loop, which assigns Tok to Tok->Next in its
initializer. This for loop has a condition to check if the result of
that isn't null. If it is, the loop is skipped and we drop back out to
the outer loop, except, now Tok is null, and we try to dereference it
without checking first.
This patch adds a defensive check that returns if Tok->Next is null
before we make it to the second for loop.
Fixes https://github.com/llvm/llvm-project/issues/82328
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
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.
The RTBS_None option in Clang-format avoids breaking after a short
return type.
However, there was an issue with the behaviour in that it wouldn't take
the leading indentation of the line into account.
This meant that the behaviour wasn't applying when intended.
In order to address this situation without breaking the existing
formatting, RTBS_None has been deprecated.
In its place are two new options for AlwaysBreakAfterReturnType.
The option RTBS_Automatic will break after the return type based on
PenaltyReturnTypeOnItsOwnLine.
The option RTBS_ExceptShortType will take the leading indentation into
account and prevent breaking after short return types.
This allows the inconsistent behaviour of RTBS_None to be avoided and
users to decide whether they want to allow breaking after short return
types or not.
Resolves#78010
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>
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
