This fixes#101363 which is a resurrection of a previously opened but
never completed review: https://reviews.llvm.org/D11851
The feature is to allow code like the following not to be broken across
multiple lines:
```
namespace foo { class bar; }
namespace foo { namespace bar { class baz; } }
```
Code like this is commonly used for forward declarations, which are
ideally kept compact. This is also apparently the format that
include-what-you-use will insert for forward declarations.
Also, fix an off-by-one error in `CompactNamespaces` code. For nested
namespaces with 3 or more namespaces, it was incorrectly compacting
lines which were 1 or two spaces over the `ColumnLimit`, leading to
incorrect formatting results.
* Convert `ReflowComments` from boolean into a new `enum` which can take
on the value `RCS_Never`, `RCS_IndentOnly`, or `RCS_Always`. The first
one is equivalent to the old `false`, the third one is `true`, and the
middle one means that multiline comments should only have their
indentation corrected, which is what Doxygen users will want.
* Preserve backward compatibility while parsing `ReflowComments`.
- Add a `CHECK_PARSE` for `AcrossComments`.
- Add a `CHECK_PARSE_NESTED_BOOL` for `AlignFunctionPointers`.
- Remove redundant statements.
- Clean up documentation.
Enabling AlignConsecutiveDeclarations also aligns function prototypes
or declarations. This is often unexpected as typically function
prototypes, especially in public headers, don't use any padding.
Setting AlignFunctionDeclarations to false will skip this alignment.
It is by default set to true to keep compatibility with prior
versions to not make unexpected changes.
Fixes#74320
Address #101550 by adding OwnLineWithBrace option for RequiresClausePosition. This permits placing a following '{' on the same line as the requires clause.
Thus, instead of:
```
bool Foo ()
requires(true)
{
return true;
}
```
we have:
```
bool Foo ()
requires(true) {
return true;
}
```
If the function body is empty, we'll get:
```
bool Foo ()
requires(true) {}
```
I attempted to get a line break between the open and close braces, but
failed. Perhaps that's fine -- it's rare and only happens in the empty
body case.
By default, clang-format packs binary operations, but it may be
desirable to have compound operations be on individual lines instead of
being packed.
This PR adds the option `BreakBinaryOperations` to break up large
compound binary operations to be on one line each.
This applies to all logical and arithmetic/bitwise binary operations
Maybe partially addresses #79487 ?
Closes#58014Closes#57280
The __attribute((specifier-list)) currently is formatted based on the
SpacesInParensOptions.Other (previously, SpacesInParentheses). This
change allows finer control over addition of spaces between the
consecutive parens, and between the inner parens and the list of
attribute specifiers.
Differential Revision: https://reviews.llvm.org/D155529
This is migrated from Phabricator, see more discussion there.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
The options regarding which blank lines are kept are also aggregated.
The new option is `KeepEmptyLines`.
This patch was initially part of 9267f8f19a2e502e. I neglected to check
the server builds before I added it. It broke clangd. Jie Fu fixed the
problem in 4c91b49bab0728d4. I was unaware of it. I thought the main
branch was still broken. I reverted the first patch in
70cfece24d6cbb57. It broke his fix. He reverted it in
c69ea04fb9738db2. Now the feature is added again including the fix.
This reverts commit 9267f8f19a2e502ef5a216c0d52b352b3699d399.
I changed a formatter option. I forgot to update other components that
depend on the formatter when the option name changed.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
24 under clang/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
When serializing a formatting style to YAML, we were emitting a comment
`# BasedOnStyle: <style>` if the serialized formatting style matches one
of the known styles. This is useful, but mis-uses the YAML API.
An upcoming change to fix keys with special characters by quoting them
breaks this,
and will emit a non-comment **key** `'# BasedOnStyle': <style>` instead.
(https://github.com/llvm/llvm-project/pull/88763)
Thus, remove this hack. There doesn't seem to be a specific use for it,
and it is not tested.
If we want the comment back, we should add comment support to the YAML writer,
and use that instead.
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
Running clang-format on the following input
```
int lambdas() {
return [&] {
return [&] {
return [&] {
return [&] {
return [&] {
return [&] {
return [&] { return 3; } ();
} (); } (); } (); } (); } (); } (); }
```
will finish instantly if you pass clang-format a .cpp input with this
content, but hang for tens of seconds if you pass the same via stdin
or a .h file.
Adding some debug statements showed that guessIsObjC was getting called
tens of millions of times in a manner that scales very rapidly with the
amount of nesting (if clang-format just takes a few seconds with that
input passed on stdin, try adding a couple more levels of nesting).
This change moves the recursive guessIsObjC call one level of nesting
out of an inner loop whose iterations don't affect the input to the
recursive call. This resolves the performance issue.
Authored-by: davidvc1 and Uran198
Differential Revision: https://reviews.llvm.org/D114837
Differential Revision: https://reviews.llvm.org/D47515
Changes the option to BreakAfterReturnType option, with a more relevant
name, deprecating and replacing AlwaysBreakAfterReturnType.
Following up on #78010.
