Summary:
This fixes a bug in clang-format where the last line's penalty is not
taken into account when its ending is broken. Usually the last line's penalty
is handled by addNextStateToQueue, but in cases where the trailing `*/` is put
on a newline, the contents of the last line have to be considered for penalizing.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50378
llvm-svn: 339123
Summary:
Previously, clang-format would avoid breaking before the first `{`
found, but then happily break before subsequent '{'s on the line. This
change fixes that by looking for the first location that has no opening
curly, if any.
This fixes the original commit by correcting the loop condition.
This reverts commit 66dc646e09b795b943668179c33d09da71a3b6bc.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50249
llvm-svn: 338890
Summary:
Previously, clang-format would avoid breaking before the first `{`
found, but then happily break before subsequent '{'s on the line. This
change fixes that by looking for the first location that has no opening
curly, if any.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50230
llvm-svn: 338837
Summary:
Previously, clang-format would crash if it tried to wrap an overlong
single line comment, because two parts of the code inserted a break in
the same location.
/** heregoesalongcommentwithnospace */
This wasn't previously noticed as it could only trigger for an overlong
single line comment that did have no breaking opportunities except for a
whitespace at the very beginning.
This also introduces a check for JavaScript to not ever wrap a comment
before an opening curly brace:
/** @mods {donotbreakbeforethecurly} */
This is because some machinery parsing these tags sometimes supports
breaks before a possible `{`, but in some other cases does not.
Previously clang-format was careful never to wrap a line with certain
tags on it. The better solution is to specifically disable wrapping
before the problematic token: this allows wrapping and aligning comments
but still avoids the problem.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50177
llvm-svn: 338706
Summary:
Bug was caused due to comments at the start of scope. For a code like:
```
int func() { //
int b;
int c;
}
```
the comment at the first line gets IndentAndNestingLevel (1,1) whereas
the following declarations get only (0,1) which prevents them from insertion
of a new scope. So, I changed the AlignTokenSequence to look at previous
*non-comment* token when deciding whether to introduce a new scope into
stack or not.
Patch by Kadir Cetinkaya!
Reviewers: rsmith, djasper
Reviewed By: djasper
Subscribers: lebedev.ri, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43303
llvm-svn: 338578
Summary:
This patch makes clang-format indent the subsequent lines created by breaking a
long javadoc annotated line.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: acoomans, cfe-commits
Differential Revision: https://reviews.llvm.org/D49797
llvm-svn: 338232
Reapply D47195:
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.
llvm-svn: 336521
Reduce penalty for aligning ObjC method arguments using the colon alignment as
this is the canonical way.
Trying to fit a whole expression into one line should not force other line
breaks (e.g. when ObjC method expression is a part of other expression).
llvm-svn: 336520
Summary:
Counts selector parts also for method declarations and counts correctly for methods without arguments.
This is an internal change and doesn't influence formatting on its own (at the current state). Its lack would be visible after applying D48719.
Reviewers: benhamilton, klimek
Reviewed By: benhamilton
Subscribers: acoomans, cfe-commits
Differential Revision: https://reviews.llvm.org/D48716
llvm-svn: 336518
Summary:
In D44638, I partially fixed `NS_SWIFT_NAME(foo(bar:baz:))`-style
annotations on C functions, but didn't add a test for Objective-C
method declarations.
For ObjC method declarations which are annotated with `NS_SWIFT_NAME(...)`,
we currently fail to annotate the final component of the selector
name as `TT_SelectorName`.
Because the token type is left unknown, clang-format will happily
cause a compilation error when it changes the following:
```
@interface Foo
- (void)doStuffWithFoo:(id)name
bar:(id)bar
baz:(id)baz
NS_SWIFT_NAME(doStuff(withFoo:bar:baz:));
@end
```
to:
```
@interface Foo
- (void)doStuffWithFoo:(id)name
bar:(id)bar
baz:(id)baz
NS_SWIFT_NAME(doStuff(withFoo:bar:baz
:));
@end
```
(note the linebreak before the final `:`).
The logic which decides whether or not to annotate the token before a
`:` with `TT_SelectorName` is pretty fragile, and has to handle some
pretty odd cases like pair-parameters:
```
[I drawRectOn:surface ofSize:aa:bbb atOrigin:cc:dd];
```
So, to minimize the effect of this change, I decided to only annotate
unknown identifiers before a `:` as `TT_SelectorName` for Objective-C
declaration lines.
Test Plan: New tests included. Confirmed tests failed before change and
passed after change. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, krasimir, jolesiak
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48679
llvm-svn: 335983
Summary: This adds a few more common function names expecting a text proto argument.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48760
llvm-svn: 335978
Summary:
This stops clang-format from touching raw string contents with unrecognized delimiters inside recognized functions.
Unrecognized delimiters signal that the string might be special.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48728
llvm-svn: 335876
Summary:
Tools that reformat code often call `getStyle` to decide the format style
to use on a certain source file. In practice, "file" style is widely used. As a
result, many tools hardcode "file" when calling `getStyle`, which makes it hard
to control the default style in tools across a codebase when needed. This change
introduces a `DefaultFormatStyle` constant (default to "file" in upstream), which
can be modified downstream if wanted, so that all users/tools built from the same
source tree can have a consistent default format style.
This also adds an DefaultFallbackStyle that is recommended to be used by tools and can be modified downstream.
Reviewers: sammccall, djasper
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48492
llvm-svn: 335492
Summary:
In C++ code snippets of the form `@field` are common. This makes clang-format
keep them together in text protos, whereas before it would break them.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48543
llvm-svn: 335459
Summary:
The case of end-of-file comments was formatted badly:
```
key: value
# end-of-file comment
```
This patch fixes that formatting:
```
key: value
# end-of-file comment
```
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48539
llvm-svn: 335449
ScopedMacroState injects its own EOF token under certain conditions, and the
returned token may be modified in several different locations. If multiple
reformat operations are started in different threads, then they will both see
the same fake EOF token, and may both try to modify it. This is a data race.
This bug was caught with tsan.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47759
llvm-svn: 334801
WebKit C++ style for object initialization is as follows:
Foo foo { bar };
Yet using clang-format -style=webkit changes this to:
Foo foo{ bar };
As there is no existing combination of rules that will ensure a space
before a braced list in this fashion, this patch adds a new
SpaceBeforeCpp11BracedList rule.
Patch by Ross Kirsling!
Differential Revision: https://reviews.llvm.org/D46024
llvm-svn: 334692
Summary:
The added test case was currently crashing with an assertion:
```
krasimir@krasimir> cat test.cc ~
// How to run:
// bbbbb run \
// rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr \
// <log_file> -- --output_directory="<output_directory>"
krasimir@krasimir> ~/work/llvm-build/bin/clang-format test.cc ~
clang-format: /usr/local/google/home/krasimir/work/llvm/tools/clang/lib/Format/WhitespaceManager.cpp:117: void clang::format::WhitespaceManager::calculateLineBreakInformation(): Assertion `PreviousOriginalWhitespaceEndOffset <= OriginalWhitespaceStartOffset' failed.
```
The root cause was that BreakableToken was not considering the case of a reflow between an unescaped newline in a line comment.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48089
llvm-svn: 334527
Summary:
Currently clang-format allows this for text protos:
```
submessage:
{ key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' }
```
when it is under the column limit and when putting it all on one line exceeds the column limit.
This is not a very intuitive formatting, so I'd prefer having
```
submessage: {
key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
}
```
instead, even if it takes one line more.
This patch prevents clang-format from inserting a break between `: {` and similar cases.
Reviewers: djasper, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48063
llvm-svn: 334517
Summary:
TypeScript uses the `!` token for strict property initialization
assertions, as in:
class X {
strictPropAsserted!: string;
}
Previously, clang-format would wrap between the `!` and the `:` for
overly long lines. This patch fixes that by generally preventing the
wrap in that location.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48030
llvm-svn: 334415
Summary:
This option replaces the BreakBeforeInheritanceComma option with an
enum, thus introducing a mode where the colon stays on the same line as
constructor declaration:
// When it fits on line:
class A : public B, public C {
...
};
// When it does not fit:
class A :
public B,
public C {
...
};
This matches the behavior of the `BreakConstructorInitializers` option,
introduced in https://reviews.llvm.org/D32479.
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: mzeren-vmw, cfe-commits
Differential Revision: https://reviews.llvm.org/D43015
llvm-svn: 334408
Summary:
This patch updates clang-format text protos to put entries of a submessage into separate lines if the submessage contains at least two entries and contains at least one submessage entry.
For example, the entries here are kept on separate lines even if putting them on a single line would be under the column limit:
```
message: {
entry: 1
submessage: { key: value }
}
```
Messages containing a single submessage or several scalar entries can still be put on one line if they fit:
```
message { submessage { key: value } }
message { x: 1 y: 2 z: 3 }
```
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46757
llvm-svn: 334401
Summary: We were missing the case when python-style comments in text protos start with `##`.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47870
llvm-svn: 334179
Summary:
Please take a close look at this CL. I haven't touched much of
`UnwrappedLineParser` before, so I may have gotten things wrong.
Previously, clang-format would incorrectly format the following:
```
@implementation Foo
- (Class)class {
}
- (void)foo {
}
@end
```
as:
```
@implementation Foo
- (Class)class {
}
- (void)foo {
}
@end
```
The problem is whenever `UnwrappedLineParser::parseStructuralElement()`
sees any of the keywords `class`, `struct`, or `enum`, it calls
`parseRecord()` to parse them as a C/C++ record.
This causes subsequent lines to be parsed incorrectly, which
causes them to be indented incorrectly.
In Objective-C/Objective-C++, these keywords are valid selector
components.
This diff fixes the issue by explicitly handling `+` and `-` lines
inside `@implementation` / `@interface` / `@protocol` blocks
and parsing them as Objective-C methods.
Test Plan: New tests added. Ran tests with:
make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, klimek
Reviewed By: jolesiak, klimek
Subscribers: klimek, cfe-commits, Wizard
Differential Revision: https://reviews.llvm.org/D47095
llvm-svn: 333553
Summary:
Reapply reverted changes from D46879.
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.
Test Plan:
make -j12 FormatTests && tools/clang/unittests/Format/FormatTests
Reviewers: benhamilton, krasimir
Reviewed By: benhamilton, krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D47195
llvm-svn: 333171
Summary:
This patch fixes two bugs in clang-format where the template wrapper doesn't skip over
comments causing a long template declaration to not be split into multiple lines.
These were latent and exposed by r332436.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D47257
llvm-svn: 333085
Summary:
`is` type annotations can occur at any nesting level. For example:
function x() {
return function y(): a is B { ... };
}
Breaking before the `is` above breaks TypeScript parsing the code. This
change prevents the wrap.
Reviewers: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D47193
llvm-svn: 332968
Summary:
Previously, clang-format's parser would fail to annotate the
selector in a single-component Objective-C method invocation with
`TT_SelectorName`. For example, the following:
[foo bar];
would parse `bar` as `TT_Unknown`:
M=0 C=1 T=Unknown S=0 B=0 BK=0 P=140 Name=identifier L=34 PPK=2
FakeLParens= FakeRParens=0 II=0x559d5db51770 Text='bar'
This caused us to fail to insert a space after a closing cast rparen,
so the following:
[((Foo *)foo) bar];
would format as:
[((Foo *)foo)bar];
This diff fixes the issue by ensuring we annotate the selector
in a single-component Objective-C method invocation as
`TT_SelectorName`.
Test Plan: New tests added. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak
Reviewed By: jolesiak
Subscribers: Wizard, klimek, hokein, cfe-commits
Differential Revision: https://reviews.llvm.org/D47028
llvm-svn: 332727
Summary:
clangToolingCore is linked into almost everything (incl. clang), but
not few tools need #include manipulation at this point. So pull this into a
separate library in Tooling.
Reviewers: ilya-biryukov
Subscribers: klimek, mgorny, cfe-commits, thakis
Differential Revision: https://reviews.llvm.org/D47068
llvm-svn: 332720
Summary:
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.
Test Plan:
make -j12 FormatTests && tools/clang/unittests/Format/FormatTests
Reviewers: benhamilton, djasper
Reviewed By: benhamilton
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46879
llvm-svn: 332582
Summary:
Introduce `PenaltyBreakTemplateDeclaration` to control the penalty,
and change `AlwaysBreakTemplateDeclarations` to an enum with 3 modes:
* `No` for regular, penalty based, wrapping of template declaration
* `MultiLine` for always wrapping before multi-line declarations (e.g.
same as legacy behavior when `AlwaysBreakTemplateDeclarations=false`)
* `Yes` for always wrapping (e.g. same as legacy behavior when
`AlwaysBreakTemplateDeclarations=true`)
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42684
llvm-svn: 332436
Summary:
This patch changes the behavior of PenaltyBreakBeforeFirstCallParameter
so that is does not apply after a brace, when Cpp11BracedListStyle is
false.
This way, variable initialization is wrapped more like an initializer
than like a function call, which is more consistent with user
expectations for this braced list style.
With PenaltyBreakBeforeFirstCallParameter=200, this gives the following
code: (with Cpp11BracedListStyle=false)
Before :
const std::unordered_map<std::string, int> Something::MyHashTable =
{ { "aaaaaaaaaaaaaaaaaaaaa", 0 },
{ "bbbbbbbbbbbbbbbbbbbbb", 1 },
{ "ccccccccccccccccccccc", 2 } };
After :
const std::unordered_set<std::string> Something::MyUnorderedSet = {
{ "aaaaaaaaaaaaaaaaaaaaa", 0 },
{ "bbbbbbbbbbbbbbbbbbbbb", 1 },
{ "ccccccccccccccccccccc", 2 }
};
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43290
llvm-svn: 332434
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Explicitly avoided changing the strings in the clang-format tests.
Differential Revision: https://reviews.llvm.org/D44975
llvm-svn: 332350
Daniel Jasper