Summary:
After D50078, we're experiencing unexpected un-indent using a style combining `AlignOperands: DontAlign` with `BreakBeforeTernaryOperators: false`, such as Google's JavaScript style:
```
% bin/clang-format -style=google ~/test.js
aaaaaaaaaaa = bbbbbbbb ? cccccccccccccccccc() :
dddddddddd ? eeeeeeeeeeeeee :
fffff;
```
The issue lies with the interaction of `AlignOperands: DontAlign` and the edited code section in ContinuationIndenter.cpp, which de-dents the intent by `Style.ContinuationIndentWidth`. From [[ ac3e5c4d93/clang/include/clang/Format/Format.h (L170) | the documentation ]] of AlignOperands: DontAlign:
> The wrapped lines are indented `ContinuationIndentWidth` spaces from the start of the line.
So the de-dent effectively erases the necessary `ContinuationIndentWidth` in that case.
This patch restores the `AlignOperands: DontAlign` behavior, producing:
```
% bin/clang-format -style=google ~/test.js
aaaaaaaaaaa = bbbbbbbb ? cccccccccccccccccc() :
dddddddddd ? eeeeeeeeeeeeee :
fffff;
```
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D82199
Summary:
This patch fixes bug #44192
When clang-format is run with option AllowShortBlocksOnASingleLine, it is expected to either succeed in putting the short block with its control statement on a single line or fail and leave the block as is. When brace wrapping after control statement is activated, if the block + the control statement length is superior to column limit but the block alone is not, clang-format puts the block in two lines: one for the control statement and one for the block. This patch removes this unexpected behaviour. Current unittests are updated to check for this behaviour.
Patch By: Bouska
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D71512
Summary:
There should be no line break before the opening brace for Microsoft style property accessors when the accessor is a simple `{ get; set }`.
https://docs.microsoft.com/en-us/dotnet/csharp/properties
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D81467
Summary: This will put a space in `lock (process)` when spaces are required after keywords.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D81255
Summary:
https://bugs.llvm.org/show_bug.cgi?id=46130 from Twitter https://twitter.com/ikautak/status/1265998988232159232
I have seen this myself many times.. if you have format on save and you work in an editor where you are constantly saving (:w muscle memory)
If you are in the middle of editing and somehow you've missed a { or } in your code, somewhere, often way below where you are at the bottom of your file the namespace comment fixer will have put the namespace on the previous closing brace.
This leads to you having to fix up the bottom of the file.
This revision prevents that happening by performing an initial pass of the tokens and simply counting the number of `{` and `}` and ensuring they balance.
If they don't balance we don't do any namespace fixing as it will likely be unstable and incorrect.
Reviewed By: curdeius
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80830
Summary:
{D80144} introduce an ObjC regression
Only parse the `[]` if what follows is really an attribute
Reviewers: krasimir, JakeMerdichAMD
Reviewed By: krasimir
Subscribers: rdwampler, aaron.ballman, curdeius, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80547
Summary:
This revision is to complement {D75791} so we can be sure that we don't change any default behavior.
For now just add rules to cover AfterExternBlock, but in the future we should add cases to cover the other BraceWrapping rules for each style. This will help guard us when we change code inside of the various getXXXStyle() functions to ensure we are not breaking everyone.
Reviewed By: MarcusJohnson91
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https:
Summary:
Its currently not possible to recreate the GNU style using the `BreakBeforeBraces: Custom` style due to a lack of missing `BeforeWhile` in the `BraceWrappingFlags`
The following request was raised to add `BeforeWhile` in a `do..while` context like `BeforeElse` and `BeforeCatch` to give greater control over the positioning of the `while`
https://bugs.llvm.org/show_bug.cgi?id=42164
Reviewers: krasimir, mitchell-stellar, sammccall
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79325
Summary:
https://bugs.llvm.org/show_bug.cgi?id=33890
This revision allow the microsoft `for each(.... in ...` nonstandard C++ extension which can be used in C++/CLI to be handled as a ForEach macro.
This prevents the breaking between the for and each onto a new line
Reviewed By: JakeMerdichAMD
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80228
Summary:
The following revision follows D80115 since @MyDeveloperDay and I apparently both had the same idea at the same time, for https://bugs.llvm.org/show_bug.cgi?id=45816 and my efforts on tooling support for AMDVLK, respectively.
This option aligns adjacent bitfield separators across lines, in a manner similar to AlignConsecutiveAssignments and friends.
Example:
```
struct RawFloat {
uint32_t sign : 1;
uint32_t exponent : 8;
uint32_t mantissa : 23;
};
```
would become
```
struct RawFloat {
uint32_t sign : 1;
uint32_t exponent : 8;
uint32_t mantissa : 23;
};
```
This also handles c++2a style bitfield-initializers with AlignConsecutiveAssignments.
```
struct RawFloat {
uint32_t sign : 1 = 0;
uint32_t exponent : 8 = 127;
uint32_t mantissa : 23 = 0;
}; // defaults to 1.0f
```
Things this change does not do:
- Align multiple comma-chained bitfield variables. None of the other
AlignConsecutive* options seem to implement that either.
- Detect bitfields that have a width specified with something other
than a numeric literal (ie, `int a : SOME_MACRO;`). That'd be fairly
difficult to parse and is rare.
Patch By: JakeMerdichAMD
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80176
Summary:
https://bugs.llvm.org/show_bug.cgi?id=43845
When a '//comment' trails a consecutive alignment, it adds a whitespace
replacement within the comment token. This wasn't handled correctly in
the alignment code, which treats it as a whole token and thus double
counts it.
This can wrongly trigger the "line too long, it'll wrap" alignment-break
condition with specific lengths, causing the alignment to break for
seemingly no reason.
Patch By: JakeMerdichAMD
Reviewed By: MyDeveloperDay
Subscribers: kostyakozko, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79465
Summary:
https://bugs.llvm.org/show_bug.cgi?id=45614
`[[nodiscard]]` after a macro doesn't behave the same as an __attribute__ resulting in incorrect indentation
This revision corrects that behavior
See original Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1629756
Before:
```
class FooWidget : public nsBaseWidget {
public:
FooWidget();
NS_DECL_ISUPPORTS_INHERITED
[[nodiscard]] nsresult
FunctionOne();
[[nodiscard]] nsresult FunctionTwo();
};
```
After:
```
class FooWidget : public nsBaseWidget {
public:
FooWidget();
NS_DECL_ISUPPORTS_INHERITED
[[nodiscard]] nsresult FunctionOne();
[[nodiscard]] nsresult FunctionTwo();
};
```
Reviewed By: Abpostelnicu
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79990
Summary:
https://bugs.llvm.org/show_bug.cgi?id=44476
```template <typename T> [[nodiscard]] int a() { return 1; }```
gets incorrectly formatted to be
```template <typename T>[[nodiscard]] int a() { return 1; }```
This revision ensure there is a space between the template and the attribute
Reviewed By: JakeMerdichAMD
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79905
Summary:
https://bugs.llvm.org/show_bug.cgi?id=45942
With Chromium style (although that is not important) its just it defines PointerAligmment: Left
The following arguments `S&&` are formatted differently depending on if the class has an attribute between it and the class identifier
```
class S {
S(S&&) = default;
};
class [[nodiscard]] S {
S(S &&) = default;
};
```
The prescense of [[nodiscard]] between the `class/struct` and the `{` causes the `{` to be incorrectly seen as a `TT_FunctionLBrace` which in turn transforms all the && to be `TT_BinaryOperators` rather than `TT_PointerOrReference`, as binary operators other spacing rules come into play causing a miss format
This revision resolves this by allowing the parseRecord to consider the [[nodisscard]]
Reviewed By: Abpostelnicu
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80008
Summary:
https://bugs.llvm.org/show_bug.cgi?id=44345
When namespaces get long the namespace end comment wraps onto the next line
```
namespace would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::
went::mad::now {
void foo();
void bar();
} // namespace
// would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::went::mad::now
```
If clang-format it applied successively it will duplicate the end comment
```
namespace would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::
went::mad::now {
void foo();
void bar();
} // namespace
// would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::went::mad::now
// would:🇮🇹:save::you:🅰️:lot::of::time::if_::i::just::gave:🆙:and_::went::mad::now
```
This revision checks to ensure the end comment is not on the next line before adding yet another comment
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79935
Summary:
Even when BreakBeforeBinaryOperators is set, AlignOperands kept
aligning the beginning of the line, even when it could align the
actual operands (e.g. after an assignment).
With this patch, the operands are actually aligned, and the operator
gets aligned with the equal sign:
int aaaaa = bbbbbb
+ cccccc;
This not happen in tests, to avoid 'breaking' the indentation:
if (aaaaa
&& bbbbb)
return;
Reviewers: krasimir, djasper, klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, acoomans, cfe-commits, klimek
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D32478
Summary:
When multiple ternary operators are chained, e.g. like an if/else-if/
else-if/.../else sequence, clang-format will keep aligning the colon
with the question mark, which increases the indent for each
conditionals:
int a = condition1 ? result1
: condition2 ? result2
: condition3 ? result3
: result4;
This patch detects the situation (e.g. conditionals used in false branch
of another conditional), to avoid indenting in that case:
int a = condition1 ? result1
: condition2 ? result2
: condition3 ? result3
: result4;
When BreakBeforeTernaryOperators is false, this will format like this:
int a = condition1 ? result1 :
condition2 ? result2 :
conditino3 ? result3 :
result4;
This formatting style is referenced here:
https://www.fluentcpp.com/2018/02/27/replace-else-if-ternary-operator/
and here:
https://marcmutz.wordpress.com/2010/10/14/top-5-reasons-you-should-love-your-ternary-operator/
Reviewers: krasimir, djasper, klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: hokein, dyung, MyDeveloperDay, acoomans, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D50078
Summary:
Allow brace wrapping in C# property accessors to be controlled by configuration options.
Add new tests and revert old test results for Microsoft style to their previous state (as intended).
`FormatStyle.BraceWrapping.AfterFunction = true;` will change automatic property formatting from
```
Type MyType { get; set }
```
to
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir, MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D79000
Summary:
Currently the 'AlignConsecutive*' options incorrectly align across
elif and else statements, even if they are very far away and across
unrelated preprocessor macros.
This failed since on preprocessor run 2+, there is not enough context
about the #ifdefs to actually differentiate one block from another,
causing them to align across different blocks or even large sections of
the file.
Eg, with AlignConsecutiveAssignments:
```
\#if FOO // Run 1
\#else // Run 1
int a = 1; // Run 2, wrong
\#endif // Run 1
\#if FOO // Run 1
\#else // Run 1
int bar = 1; // Run 2
\#endif // Run 1
```
is read as
```
int a = 1; // Run 2, wrong
int bar = 1; // Run 2
```
The approach taken to fix this was to add a new flag to Token that
forces breaking alignment across groups of lines (MustBreakAlignBefore)
in a similar manner to the existing flag that forces a line break
(MustBreakBefore). This flag is set for the first Token after a
preprocessor statement or diff conflict marker.
Fixes #25167,#31281
Patch By: JakeMerdichAMD
Reviewed By: MyDeveloperDay
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79388
Summary:
https://bugs.llvm.org/show_bug.cgi?id=45639
clang-format incorrectly splits the `[[` in a long argument list
```
void SomeLongClassName::ALongMethodNameInThatClass([[maybe_unused]] const shared_ptr<ALongTypeName>& argumentNameForThat
LongType) {
}
```
becomes
```
void SomeLongClassName::ALongMethodNameInThatClass([
[maybe_unused]] const shared_ptr<ALongTypeName> &argumentNameForThatLongType) {
}
```
leaving one `[` on the previous line
For a function with just 1 very long argument, clang-format chooses to split between the `[[`,
This revision prevents the slip between the two `[` and the second `[`
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79401
Summary: systemd recently added a clang-format file. One issue I
encountered in using clang-format on systemd is that systemd does
not add a space before the parens of their foreach macros but
clang-format always adds a space. This does not seem to be
configurable in clang-format. This revision adds the
ControlStatementsExceptForEachMacros option to SpaceBeforeParens
which puts a space before all control statement parens except
ForEach macros. This drastically reduces the amount of changes
when running clang-format on systemd's source code.
Reviewers: MyDeveloperDay, krasimir, mitchell-stellar
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78869
Summary:
Ensure the clang-format unit tests are themselves clang-formatted
Having areas of the llvm code which are clang-format clean, give us more areas to run new clang-format binaries on ensuring we haven't broken anything.
It seems to me we SHOULD have this clang-formatted at a minimum, otherwise how can we expect others to use clang-format if we "don't eat our own dogfood", also if the tests are dependent on the formatting of the code then that would also be bad!
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79204
Summary: The condition added with the new setting checked whether the character was an l-brace, not specifically a lambda l-brace, when deciding whether it was possible to break before it or not. This caused the l-brace of some initialiser lists to break onto the next line with the first argument of the initialiser list when the setting was enabled.
Reviewed By: MyDeveloperDay, Wawha
Patch By: duncan-llvm
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79022
Summary:
BTW my actual code that hit this issue is like
```
[a, b = std::move(b)](auto &&... c) mutable -> std::invoke_result_t<decltype(b), decltype(c)...> { /* omitted */ }
```
where this explicit return type is required for SFINAE.
Reviewed By: krasimir, MyDeveloperDay
Patch By: johnchen902
Subscribers: krasimir, dexonsmith, cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78694
Summary:
This is a tentative fix for https://bugs.llvm.org/show_bug.cgi?id=45357
Spaces seem to be introduced between * and * due to changes brought in for {D69573}
Reviewers: sylvestre.ledru, mitchell-stellar, sammccall, Abpostelnicu, krasimir, jbcoe
Reviewed By: Abpostelnicu
Subscribers: tstellar, hans, Abpostelnicu, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D78879
Summary:
Allow brace wrapping in C# property accessors to be controlled by configuration options.
Add new tests and revert old test results for MS style to their old state (as intended).
`FormatStyle.BraceWrapping.AfterFunction = true;` will change automatic property formatting from
```
Type MyType { get; set }
```
to
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D79000
Summary:
Added some examples of properties from Microsoft documentation as test cases.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties
Configuration support will be added in a follow up patch to address whether automatic properties are formatted as
```
Type MyType { get; set }
```
or
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78915
Summary:
Improve C# `{ get; set; } = default;` formatting by handling it in the UnwrappedLineParser rather than trying to merge lines later.
Remove old logic to merge lines.
Update tests as formatting output has changed (as intended).
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78642
Summary:
Even when BreakBeforeBinaryOperators is set, AlignOperands kept
aligning the beginning of the line, even when it could align the
actual operands (e.g. after an assignment).
With this patch, there is an option to actually align the operands, so
that the operator gets right-aligned with the equal sign or return
operator:
int aaaaa = bbbbbb
+ cccccc;
return aaaaaaa
&& bbbbbbb;
This not happen in parentheses, to avoid 'breaking' the indentation:
if (aaaaa
&& bbbbb)
return;
Reviewers: krasimir, djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32478
When multiple ternary operators are chained, e.g. like an if/else-if/
else-if/.../else sequence, clang-format will keep aligning the colon
with the question mark, which increases the indent for each
conditionals:
int a = condition1 ? result1
: condition2 ? result2
: condition3 ? result3
: result4;
This patch detects the situation (e.g. conditionals used in false branch
of another conditional), to avoid indenting in that case:
int a = condition1 ? result1
: condition2 ? result2
: condition3 ? result3
: result4;
When BreakBeforeTernaryOperators is false, this will format like this:
int a = condition1 ? result1 :
condition2 ? result2 :
conditino3 ? result3 :
result4;
Summary:
Use spaces instead of tabs for alignment with UT_ForContinuationAndIndentation to make the code aligned for any tab/indent width.
Fixes https://bugs.llvm.org/show_bug.cgi?id=38381
Reviewed By: MyDeveloperDay
Patch By: fickert
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D75034
Summary:
clang-format currently puts the first enumerator on the same line as the
enum keyword and opening brace if it fits (for example, for anonymous
enums if IndentWidth is 8):
$ echo "enum { RED, GREEN, BLUE };" | clang-format -style="{BasedOnStyle: llvm, ColumnLimit: 15, IndentWidth: 8}"
enum { RED,
GREEN,
BLUE };
This doesn't seem to be intentional, as I can't find any style guide that
suggests wrapping enums this way. Always force the enumerator to be on a new
line, which gets us the desired result:
$ echo "enum { RED, GREEN, BLUE };" | ./bin/clang-format -style="{BasedOnStyle: llvm, ColumnLimit: 15, IndentWidth: 8}"
enum {
RED,
GREEN,
BLUE
};
Test Plan:
New test added. Confirmed test failed without change and passed with change by
running:
$ ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewed By: MyDeveloperDay
Patch By: osandov
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D77682
Summary:
While [the original diff](https://reviews.llvm.org/D42493) makes a lot of sense, and multiple inline block parameter/trailing paramemter after inline block paramemter should be discouraged, the formatting result is different than what xcode does by default
For the exact same example provided in the original diff:
```
[object
blockArgument:^{
a = 42;
}
anotherArg:42];
```
The code is hard to read and not very visually pleasing
This diff uses `ObjCBreakBeforeNestedBlockParam` to shield from the formatting
When it's set to false, don't allign the inline block paramemters.
Reviewers: jolesiak, benhamilton, jinlin
Reviewed By: jolesiak
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77039
Summary:
The previous change in https://reviews.llvm.org/D77311 attempted to
detect more C++ keywords. However it also precisely detected all
JavaScript keywords. That's generally correct, but many JavaScripy
keywords, e.g. `get`, are so-called pseudo-keywords. They can be used in
positions where a keyword would never be legal, e.g. in a dotted
expression:
x.type; // type is a pseudo-keyword, but can be used here.
x.get; // same for get etc.
This change introduces an additional parameter to
`IsJavaScriptIdentifier`, allowing clients to toggle whether they want
to allow `IdentifierName` tokens, i.e. pseudo-keywords.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77548
Krasimir Georgiev