Previously, we would format:
int a() { ... }
[[unused]] int b() { ... }
as...
int a() {} [[unused] int b() {}
Now we correctly format each on its own line.
Similarly, we would detect:
[[unused]] int b() { return 42; }
As a lambda and leave it on a single line, even if that was disallowed
by the format style.
llvm-svn: 329816
Summary:
Previously, `clang-format` didn't understand lightweight
Objective-C generics, which have the form:
```
@interface Foo <KeyType,
ValueTypeWithConstraint : Foo,
AnotherValueTypeWithGenericConstraint: Bar<Baz>, ... > ...
```
The lightweight generic specifier list appears before the base
class, if present, but because it starts with < like the protocol
specifier list, `UnwrappedLineParser` was getting confused and
failed to parse interfaces with both generics and protocol lists:
```
@interface Foo <KeyType> : NSObject <NSCopying>
```
Since the parsed line would be incomplete, the format result
would be very confused (e.g., https://bugs.llvm.org/show_bug.cgi?id=24381).
This fixes the issue by explicitly parsing the ObjC lightweight
generic conformance list, so the line is fully parsed.
Fixes: https://bugs.llvm.org/show_bug.cgi?id=24381
Test Plan: New tests added. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45185
llvm-svn: 329298
Summary: Extend various verifyFormat helper functions to check that the
expected text is "stable". This provides some protection against bugs
where formatting results are ocilating between two forms, or continually
change in some other way.
Testing Done:
* Ran unit tests.
* Reproduced a known instability in preprocessor indentation which was
caught by this new check.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42034
llvm-svn: 329231
Summary:
The following C++ code was being detected by
`guessLanguage()` as Objective-C:
#define FOO(...) auto bar = [] __VA_ARGS__;
This was because `[] __VA_ARGS__` is not currently detected as a C++
lambda expression (it has no parens or braces), so
`TokenAnnotator::parseSquare()` incorrectly treats the opening square
as an ObjC method expression.
We have two options to fix this:
1. Parse `[] __VA_ARGS__` explicitly as a C++ lambda
2. Make it so `[]` is never parsed as an Objective-C method expression
This diff implements option 2, which causes the `[` to be parsed
as `TT_ArraySubscriptLSquare` instead of `TT_ObjCMethodExpr`.
Note that when I fixed this, it caused one change in formatting
behavior, where the following was implicitly relying on the `[`
being parsed as `TT_ObjCMethodExpr`:
A<int * []> a;
becomes:
A<int *[]> a;
with `Style.PointerAlignment = Middle`.
I don't really know what the desired format is for this syntax; the
test was added by Janusz Sobczak and integrated by @djasper in
b511fe9818
.
I went ahead and changed the test for now.
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Fixes: https://bugs.llvm.org/show_bug.cgi?id=36248
Reviewers: djasper, jolesiak
Reviewed By: djasper
Subscribers: klimek, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D45169
llvm-svn: 329070
Summary:
D44816 attempted to fix a few cases where `clang-format` incorrectly
inserted a space before the closing brace of an Objective-C dictionary
literal.
This revealed there were still a few cases where we inserted a space
after the opening brace of an Objective-C dictionary literal.
This fixes the formatting to be consistent and adds more tests.
Test Plan: New tests added. Confirmed tests failed before
diff and passed after diff.
Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak, krasimir
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45168
llvm-svn: 329069
Summary:
In D43121, @Typz introduced logic to avoid indenting 2-or-more
argument ObjC selectors too far to the right if the first component
of the selector was longer than the others.
This had a small side effect of causing wrapped ObjC selectors with
exactly 1 argument to not obey IndentWrappedFunctionNames:
```
- (aaaaaaaaaa)
aaaaaaaaaa;
```
This diff fixes the issue by ensuring we align wrapped 1-argument
ObjC selectors correctly:
```
- (aaaaaaaaaa)
aaaaaaaaaa;
```
Test Plan: New tests added. Test failed before change, passed
after change. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, klimek, Typz, jolesiak
Reviewed By: djasper, jolesiak
Subscribers: cfe-commits, Typz
Differential Revision: https://reviews.llvm.org/D44994
llvm-svn: 328871
Summary:
This fixes an issue brought up by djasper@ in his review of D44790. We
handled top-level child lines, but if those child lines themselves
had child lines, we didn't handle them.
Rather than use recursion (which could blow out the stack), I use a
DenseSet to hold the set of lines we haven't yet checked (since order
doesn't matter), and update the set to add the children of each
line as we check it.
Test Plan: New tests added. Confirmed tests failed before fix
and passed after fix.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44831
llvm-svn: 328628
Summary:
Previously, `clang-format` would sometimes insert a space
before the closing brace in an Objective-C dictionary literal.
Unlike array literals (which obey `Style.SpacesInContainerLiterals`
to add a space after `[` and before `]`), Objective-C dictionary
literals currently are not meant to insert a space after `{` and before
`}`, regardless of `Style.SpacesInContainerLiterals`.
However, some constructs like `@{foo : @(bar)}` caused `clang-format`
to insert a space between `)` and `}`.
This fixes the issue and adds tests. (I understand the behavior is
not consistent between array literals and dictionary literals, but
that's existing behavior that's a much larger change.)
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak, Wizard
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44816
llvm-svn: 328627
Summary:
When I wrote `ObjCHeaderStyleGuesser`, I incorrectly assumed the
correct way to iterate over all tokens in `AnnotatedLine` was to
iterate over the linked list tokens starting with
`AnnotatedLine::First`.
However, `AnnotatedLine` also contains a vector
`AnnotedLine::Children` with child `AnnotedLine`s which have their own
tokens which we need to iterate over.
Because I didn't iterate over the tokens in the children lines, the
ObjC style guesser would fail on syntax like:
#define FOO ({ NSString *s = ... })
as the statement(s) inside { ... } are child lines.
This fixes the bug and adds a test. I confirmed the test
failed before the fix, and passed after the fix.
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak, Wizard
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44790
llvm-svn: 328220
For multiline raw string literals, we generally want to respect the
author's choice of linebreak before the 'R"(' as the rest of the raw
string might be aligned to it and we cannot (commonly) modify the
content.
For single-line raw string literals, this doesn't make any sense and so
we should just treat them as regular string literals in this regard.
llvm-svn: 328201
When SpacesInParentheses is set to true clang-format does not add a
space before fully qualified names. For example:
do_something(::globalVar );
Fix by Darby Payne. Thank you!
llvm-svn: 328200
Summary:
We received reports of the Objective-C style guesser getting a false
negative on header files like:
CGSize SizeOfThing(MyThing thing);
This adds more Core Graphics identifiers to the Objective-C style
guesser.
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, djasper
Reviewed By: jolesiak, djasper
Subscribers: krasimir, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44632
llvm-svn: 328175
Summary:
Previously, clang-format would insert a space between
the closing parenthesis and 'new' in the following valid Objective-C
declaration:
+ (instancetype)new;
This was because 'new' is treated as a keyword, not an identifier.
TokenAnnotator::spaceRequiredBefore() already handled the case where
r_paren came before an identifier, so this diff extends it to
handle r_paren before 'new'.
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak, stephanemoore
Reviewed By: djasper, jolesiak, stephanemoore
Subscribers: stephanemoore, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44692
llvm-svn: 328174
Summary:
Objective-C selectors with arguments take the form of:
foo:
foo:bar:
foo:bar:baz:
These can be passed to a macro, like NS_SWIFT_NAME():
https://developer.apple.com/library/content/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html
and must never have spaces inserted around the colons.
Previously, there was logic in TokenAnnotator's tok::colon parser to
handle the single-argument case, but it failed for the
multiple-argument cases.
This diff fixes the bug and adds more tests.
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, djasper, Wizard
Reviewed By: jolesiak, Wizard
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44638
llvm-svn: 327986
Summary:
This addresses bug 36766 and a FIXME in tests about empty lines before
`}[;] // comment` lines.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44631
llvm-svn: 327861
Summary: This disallows patterns like `[ext.name\n]` in text protos.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44569
llvm-svn: 327716
Summary: We weren't penalizing cases where the raw string prefix goes over the column limit.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44563
llvm-svn: 327708
Summary:
Previously, clang-format would detect the following as an
Objective-C block type:
FOO(^);
when it actually must be a C or C++ macro dealing with an XOR
statement or an XOR operator overload.
According to the Clang Block Language Spec:
https://clang.llvm.org/docs/BlockLanguageSpec.html
block types are of the form:
int (^)(char, float)
and block variables of block type are of the form:
void (^blockReturningVoidWithVoidArgument)(void);
int (^blockReturningIntWithIntAndCharArguments)(int, char);
void (^arrayOfTenBlocksReturningVoidWithIntArgument[10])(int);
This tightens up the detection so we don't unnecessarily detect
C macros which pass in the XOR operator.
Depends On D43904
Test Plan: New tests added. Ran tests with:
make -j12 FormatTests &&
./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, jolesiak, djasper
Reviewed By: djasper
Subscribers: djasper, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D43906
llvm-svn: 327285
Summary:
Previously, clang-format would detect C++11 and C++17 attribute
specifiers like the following as Objective-C method invocations:
[[noreturn]];
[[clang::fallthrough]];
[[noreturn, deprecated("so sorry")]];
[[using gsl: suppress("type")]];
To fix this, I ported part of the logic from
tools/clang/lib/Parse/ParseTentative.cpp into TokenAnnotator.cpp so we
can explicitly parse and identify C++11 attribute specifiers.
This allows the guessLanguage() and getStyle() APIs to correctly
guess files containing the C++11 attribute specifiers as C++,
not Objective-C.
Test Plan: New tests added. Ran tests with:
make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, jolesiak, djasper
Reviewed By: djasper
Subscribers: aaron.ballman, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D43902
llvm-svn: 327284
Three issues to fix:
- char_constants weren't properly treated as string literals
- Prevening the break after "label: " does not make sense in concunction
with AlwaysBreakBeforeMultilineStrings. It leads to situations where
clang-format just cannot find a viable format (it must break and yet
it must not break).
- AlwaysBreakBeforeMultilineStrings should not be on for LK_TextProto in
Google style.
llvm-svn: 327255
Summary:
This makes the formatter of raw string literals use NestedBlockIndent for
determining the 0 column of the content inside. This makes the formatting use
less horizonal space and fixes a case where two newlines before and after the
raw string prefix were selected instead of a single newline after it:
Before:
```
aaaa = ffff(
R"pb(
key: value)pb");
```
After:
```
aaaa = ffff(R"pb(
key: value)pb");
```
Reviewers: djasper, sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44141
llvm-svn: 326996
Summary:
This patch fixes a bug where consecutive string literals in text protos were
put on the same line.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44204
llvm-svn: 326945
Summary:
Previously, clang-format would detect the following as an
Objective-C for-in statement:
for (int x = in.value(); ...) {}
because the logic only decided a for-loop was definitely *not*
an Objective-C for-in loop after it saw a semicolon or a colon.
To fix this, I delayed the decision of whether this was a for-in
statement until after we found the matching right-paren, at which
point we know if we've seen a semicolon or not.
Test Plan: New tests added. Ran tests with:
make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, jolesiak
Reviewed By: jolesiak
Subscribers: djasper, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D43904
llvm-svn: 326815
Summary:
Code that used to be formatted as `if (! + object) {` is now formatted as `if (!+object) {`
(we have a particular object in our codebase where unary `operator+` is overloaded to return the underlying value, which in this case is a `bool`)
We still preserve the TypeScript behavior where `!` is a trailing non-null operator. (This is already tested by an existing unit test in `FormatTestJS.cpp`)
It doesn't appear like handling of consecutive unary operators are tested in general, so I added another test for completeness
Patch contributed by @kevinl!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43312
llvm-svn: 326792
Summary:
When disabled, this option allows removing the space before colon,
making it act more like the semi-colon. When enabled (default), the
current behavior is not affected.
This mostly affects C++11 loop, initializer list, inheritance list and
container literals:
class Foo: Bar {}
Foo::Foo(): a(a) {}
for (auto i: myList) {}
f({a: 1, b: 2, c: 3});
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: xvallspl, teemperor, karies, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32525
llvm-svn: 326426
Summary: This fixes a glitch where ``operator: value`` in a text proto would mess up the underlying formatting since it gets parsed as a kw_operator instead of an identifier.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43830
llvm-svn: 326227
Summary:
This fixes a few issues djasper@ brought up in his review of D43522.
Test Plan:
make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43598
llvm-svn: 326205
ObjC defines `@autoreleasepool` and `@synchronized` control blocks. These
used to be formatted according to the `AfterObjCDeclaration` brace-
wrapping flag, which is not very consistent.
This patch changes the behavior to use the `AfterControlStatement` flag
instead. This should not affect the behavior unless a custom brace
wrapping mode is used.
Reviewers: krasimir, djasper, klimek, benhamilton
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43232
llvm-svn: 326192
Summary:
The blocks used to be formatted using the "default" behavior, and would
thus be mistaken for function calls followed by blocks: this could lead
to unexpected inlining of the block and extra line-break before the
opening brace.
They are now formatted similarly to `@autoreleasepool` blocks, as
expected:
@synchronized(self) {
f();
}
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43114
llvm-svn: 326191
Summary:
Make the new GetStyleWithEmptyFileName test case independent
of the file system used when running the test. Since the
test is supposed to use the fallback "Google" style we now
use a InMemoryFileSystem to make sure that we do not accidentaly
find a .clang-format file in the real file system. That could
for example happen when having the build directory inside the
llvm och clang repo (as there is a .clang-format file inside
the repos).
Reviewers: vsapsai, jolesiak, krasimir, benhamilton
Reviewed By: krasimir
Subscribers: uabelho, twoh, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43732
llvm-svn: 326086
Summary:
D43522 caused an assertion failure when getStyle() was called with
an empty filename:
P8065
This adds a test to reproduce the failure and fixes the issue by
ensuring we never pass an empty filename to
Environment::CreateVirtualEnvironment().
Test Plan: New test added. Ran test with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Before diff, test failed with P8065. Now, test passes.
Reviewers: vsapsai, jolesiak, krasimir
Reviewed By: vsapsai
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43590
llvm-svn: 325722
Summary:
For clients which don't have a filesystem, calling getStyle() doesn't
make much sense (there's no .clang-format files to search for).
In this diff, I hoist out the language-guessing logic from getStyle()
and move it into a new API guessLanguage().
I also added support for guessing the language of files which have no
extension (they could be C++ or ObjC).
Test Plan: New tests added. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, krasimir
Reviewed By: jolesiak, krasimir
Subscribers: klimek, cfe-commits, sammccall
Differential Revision: https://reviews.llvm.org/D43522
llvm-svn: 325691
Summary:
This fixes the detection of scope openers in text proto extensions; previously
they were not detected correctly leading to instances like:
```
msg {
[aa.bb
] {
key: value
}
}
```
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43469
llvm-svn: 325513
Summary: This patch fixes a case where a proto message attribute is wrongly identified as an text proto extension.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43465
llvm-svn: 325509
Summary:
`of` is only a keyword when after an identifier, but not when after
an actual keyword.
Before:
return of (a, b, c);
After:
return of(a, b, c);
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D43440
llvm-svn: 325489
Summary:
Frequently, a percent in protos denotes a formatting specifier for string replacement.
Thus it is desirable to keep the percent together with what follows after it.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43294
llvm-svn: 325159
Summary: This patch fixes a bug where the comment indent of comments in text protos gets messed up because by default paren states get created with AlignColons = true (which makes snese for ObjC).
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43194
llvm-svn: 324896
Summary:
When the target object expression is short and the first selector name
is long, clang-format used to break the colon alignment:
[I performSelectorOnMainThread:@selector(loadAccessories)
withObject:nil
waitUntilDone:false];
This happens because the colon is placed at `ContinuationIndent +
LongestObjCSelectorName`, so that any selector can be wrapped. This is
however not needed in case the longest selector is the firstone, and
not wrapped.
To overcome this, this patch does not include the first selector in
`LongestObjCSelectorName` computation (in TokenAnnotator), and lets
`ContinuationIndenter` decide how to account for the first selector
when wrapping. (Note this was already partly the case, see line 521
of ContinuationIndenter.cpp)
This way, the code gets properly aligned whenever possible without
breaking the continuation indent.
[I performSelectorOnMainThread:@selector(loadAccessories)
withObject:nil
waitUntilDone:false];
[I // force break
performSelectorOnMainThread:@selector(loadAccessories)
withObject:nil
waitUntilDone:false];
[I perform:@selector(loadAccessories)
withSelectorOnMainThread:true
waitUntilDone:false];
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43121
llvm-svn: 324741
Summary:
Concatenating Objective-C string literals inside an array literal
raises the warning -Wobjc-string-concatenation (which is enabled by default).
clang-format currently splits and concatenates string literals like
the following:
NSArray *myArray = @[ @"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" ];
into:
NSArray *myArray =
@[ @"aaaaaaaaaaaaaaaaaaaaaaaaaaaa"
@"aaaaaaaaa" ];
which raises the warning. This is https://bugs.llvm.org/show_bug.cgi?id=36153 .
The options I can think of to fix this are:
1) Have clang-format disable Wobjc-string-concatenation by emitting
pragmas around the formatted code
2) Have clang-format wrap the string literals in a macro (which
disables the warning)
3) Disable string splitting for Objective-C string literals inside
array literals
I think 1) has no precedent, and I couldn't find a good
identity() macro for 2). So, this diff implements 3).
Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, stephanemoore, djasper
Reviewed By: jolesiak
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42704
llvm-svn: 324618
Summary:
This patch is a follow-up to r323319 (which disables string literal breaking for
text protos) and it disables breaking before long string literals.
For example this:
```
keyyyyy: "long string literal"
```
used to get broken into:
```
keyyyyy:
"long string literal"
```
While at it, I also enabled it for LK_Proto and fixed a bug in the mustBreak code.
Reviewers: djasper, sammccall
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42957
llvm-svn: 324591
Summary:
This is split off from D42650, and sets ObjCBinPackProtocolList
to Never for the google style.
Depends On D42650
Test Plan: New tests added. make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, jolesiak, stephanemoore
Reviewed By: krasimir, jolesiak, stephanemoore
Subscribers: klimek, cfe-commits, hokein, Wizard
Differential Revision: https://reviews.llvm.org/D42708
llvm-svn: 324553
Summary:
Fixes formatting of ObjC message arguments when inline block is a first
argument.
Having inline block as a first argument when method has multiple parameters is
discouraged by Apple:
"It’s best practice to use only one block argument to a method. If the
method also needs other non-block arguments, the block should come last"
(https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithBlocks/WorkingwithBlocks.html#//apple_ref/doc/uid/TP40011210-CH8-SW7),
it should be correctly formatted nevertheless.
Current formatting:
```
[object blockArgument:^{
a = 42;
}
anotherArg:42];
```
Fixed (colon alignment):
```
[object
blockArgument:^{
a = 42;
}
anotherArg:42];
```
Test Plan: make -j12 FormatTests && tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, benhamilton
Reviewed By: krasimir, benhamilton
Subscribers: benhamilton, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42493
llvm-svn: 324469
Summary:
In r236412, @djasper added a comment:
// FIXME: We likely want to do this for more combinations of brackets.
// Verify that it is wanted for ObjC, too.
In D42650, @stephanemoore asked me to confirm this.
This followup to D42650 adds more tests to verify the relative
alignment behavior for Objective-C 2.0 generics passed to functions
and removes the second half of the FIXME comment.
Test Plan:
make -j12 FormatTests && \
./tools/clang/unittests/Format/FormatTests --gtest_filter=FormatTestObjC.\*
Reviewers: stephanemoore, jolesiak, djasper
Reviewed By: jolesiak
Subscribers: klimek, cfe-commits, djasper, stephanemoore, krasimir
Differential Revision: https://reviews.llvm.org/D42864
llvm-svn: 324364
Summary:
This patch adds spaces around angle brackets in text proto Google style.
Previously these were detected as template openers and closers, which happened
to have the expected effect. Now we detect them as scope openers and closers
similarly to the way braces are handled in this context.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42727
llvm-svn: 324337
Summary:
When a preprocessor indent closes after the last line of normal code we do not
correctly fixup include guard indents. For example:
#ifndef HEADER_H
#define HEADER_H
#if 1
int i;
# define A 0
#endif
#endif
incorrectly reformats to:
#ifndef HEADER_H
#define HEADER_H
#if 1
int i;
# define A 0
# endif
#endif
To resolve this issue we must fixup levels after parseFile(). Delaying
the fixup introduces a new state, so consolidate include guard search
state into an enum.
Reviewers: krasimir, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42035
llvm-svn: 324246
Summary:
When a preprocessor indent closes after the last line of normal code we do not
correctly fixup include guard indents. For example:
#ifndef HEADER_H
#define HEADER_H
#if 1
int i;
# define A 0
#endif
#endif
incorrectly reformats to:
#ifndef HEADER_H
#define HEADER_H
#if 1
int i;
# define A 0
# endif
#endif
To resolve this issue we must fixup levels after parseFile(). Delaying
the fixup introduces a new state, so consolidate include guard search
state into an enum.
Reviewers: krasimir, klimek
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42035
llvm-svn: 324238
Summary:
This is an alternative approach to D42014 after some
investigation by stephanemoore@ and myself.
Previously, the format parameter `BinPackParameters` controlled both
C function parameter list bin-packing and Objective-C protocol conformance
list bin-packing.
We found in the Google style, some teams were changing
`BinPackParameters` from its default (`true`) to `false` so they could
lay out Objective-C protocol conformance list items one-per-line
instead of bin-packing them into as few lines as possible.
To allow teams to use one-per-line Objective-C protocol lists without
changing bin-packing for other areas like C function parameter lists,
this diff introduces a new LibFormat parameter
`ObjCBinPackProtocolList` to control the behavior just for ObjC
protocol conformance lists.
The new parameter is an enum which defaults to `Auto` to keep the
previous behavior (delegating to `BinPackParameters`).
Depends On D42649
Test Plan: New tests added. make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, stephanemoore, djasper
Reviewed By: stephanemoore
Subscribers: Wizard, hokein, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D42650
llvm-svn: 324131
Summary:
r312125, which introduced preprocessor indentation, shipped with a known
issue where "indentation of comments immediately before indented
preprocessor lines is toggled on each run". For example these two forms
toggle:
#ifndef HEADER_H
#define HEADER_H
#if 1
// comment
# define A 0
#endif
#endif
#ifndef HEADER_H
#define HEADER_H
#if 1
// comment
# define A 0
#endif
#endif
This happens because we check vertical alignment against the '#' yet
indent to the level of the 'define'. This patch resolves this issue by
aligning against the '#'.
Reviewers: krasimir, klimek, djasper
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42408
llvm-svn: 323904
Summary:
This patch modifies the text proto Google style to add spaces around braces.
I investigated using something different than Cpp11BracedListStyle, but it turns out it's what we want and also the java and js styles also depend on that.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42685
llvm-svn: 323860
Summary:
The existing unit tests in FormatTestObjC.cpp didn't fully cover
all the cases for protocol confirmance list formatting.
This extends the unit tests to more cases of protocol
conformance list formatting, especially how the behavior changes
when `BinPackParameters` changes from `true` (the default) to `false`.
Test Plan: make -j12 FormatTests && \
./tools/clang/unittests/Format/FormatTests --gtest_filter=FormatTestObjC.\*
Reviewers: krasimir, jolesiak, stephanemoore
Reviewed By: krasimir
Subscribers: benhamilton, klimek, cfe-commits, hokein, Wizard
Differential Revision: https://reviews.llvm.org/D42649
llvm-svn: 323684
Summary:
JavaScript automatic semicolon insertion can trigger before [ and (, so
avoid breaking before them if the previous token is likely to terminate
an expression.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D42570
llvm-svn: 323532
Summary:
Consider the text proto:
```
message {
sub { key: value }
}
```
Previously the first `{` was TT_Unknown, which caused the inner message to be
indented by the continuation width. This didn't happen for:
```
message {
sub: { key: value }
}
```
This is because the code to mark the first `{` as a TT_DictLiteral was only
considering the case where it marches forward and reaches a `:`.
This patch updates this by looking not only for `:`, but also for `<` and `{`.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42500
llvm-svn: 323419
Summary:
This patch fixes an issue where the UnbreakableTailLength would be counted towards
the length of a token during breaking, even though we can break after the token.
For example, this proto text with column limit 20
```
# ColumnLimit: 20 V
foo: {
bar: {
bazoo: "aaaaaaa"
}
}
```
was broken:
```
# ColumnLimit: 20 V
foo: {
bar: {
bazoo:
"aaaaaaa"
}
}
```
because the 2 closing `}` were counted towards the string literal's `UnbreakableTailLength`.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42376
llvm-svn: 323188
Summary:
This patch adds canonical delimiter support to the raw string formatting.
This allows matching delimiters to be updated to the canonical one.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42187
llvm-svn: 322956
Summary:
This patch addresses bug 36002, where a combination of options causes the line
following a short block in macro to be merged with that macro.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42298
llvm-svn: 322954
Summary:
The Google style guide is neutral on whether there should be a
space before the protocol list in an Objective-C @interface or
@implementation.
The majority of Objective-C code in both Apple's public
header files and Google's open-source uses a space before
the protocol list, so this changes the google style to
default ObjCSpaceBeforeProtocolList to true.
Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, djasper, klimek
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D41074
llvm-svn: 322873
Summary:
This improves upon the previous Objective-C header guessing heuristic
from rC320479.
Now, we run the lexer on C++ header files and look for Objective-C
keywords and syntax. We also look for Foundation types.
Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, krasimir
Reviewed By: jolesiak
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42135
llvm-svn: 322690
Summary:
This patch changes the structure for raw string formatting options by making it
language based (enumerate delimiters per language) as opposed to delimiter-based
(specify the language for a delimiter). The raw string formatting now uses an
appropriate style from the .clang-format file, if exists.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D42098
llvm-svn: 322634
This reverts commit 37e69667f748e1458b46483b7c1b8f9ba33eec44.
We're going to discuss its ramifications further before making a
conclusion.
llvm-svn: 320747
Summary:
If we write the following code, it goes over 100 columns, so we need to wrap it:
```
- (VeryLongReturnTypeName)veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```
Currently, clang-format with the google style aligns the method parameter names on the first column:
```
- (VeryLongReturnTypeName)
veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```
We'd like clang-format in the google style to align these to column 4 for Objective-C:
```
- (VeryLongReturnTypeName)
veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```
Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: krasimir, djasper, klimek
Reviewed By: djasper
Subscribers: cfe-commits, thakis
Differential Revision: https://reviews.llvm.org/D41195
llvm-svn: 320714
Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.
All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.
llvm-svn: 320707
This patch improves detection of ObjC header files.
Right now many ObjC headers, especially short ones, are categorized as C/C++.
Way of filtering still isn't the best, as most likely it should be token-based.
Contributed by jolesiak!
llvm-svn: 320479
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
Before, we would not break:
int a = foo(/* trailing */);
when the end of /* trailing */ was exactly the column limit; the reason
is that block comments can have an unbreakable tail length - in this case
2, for the trailing ");"; we would unconditionally account that when
calculating the column state at the end of the token, but not correctly
add it into the remaining column length before, as we do for string
literals.
The fix is to correctly account the trailing unbreakable sequence length
into our formatting decisions for block comments. Line comments cannot
have a trailing unbreakable sequence, so no change is needed for them.
llvm-svn: 319642
When we break a long line like:
Column limit: 21
|
// foo foo foo foo foo foo foo foo foo foo foo foo
The local decision when to allow protruding vs. breaking can lead to this
outcome (2 excess characters, 2 breaks):
// foo foo foo foo foo
// foo foo foo foo foo
// foo foo
While strictly staying within the column limit leads to this strictly better
outcome (fully below the column limit, 2 breaks):
// foo foo foo foo
// foo foo foo foo
// foo foo foo foo
To get an optimal solution, we would need to consider all combinations of excess
characters vs. breaking for all lines, but that would lead to a significant
increase in the search space of the algorithm for little gain.
Instead, we blindly try both approches and·select the one that leads to the
overall lower penalty.
Differential Revision: https://reviews.llvm.org/D40605
llvm-svn: 319541
This fixes some bugs in the reflowing logic and splits out the concerns
of reflowing from BreakableToken.
Things to do after this patch:
- Refactor the breakProtrudingToken function possibly into a class, so we
can split it up into methods that operate on the common state.
- Optimize whitespace compression when reflowing by using the next possible
split point instead of the latest possible split point.
- Retry different strategies for reflowing (strictly staying below the
column limit vs. allowing excess characters if possible).
Differential Revision: https://reviews.llvm.org/D40310
llvm-svn: 319314
Summary:
This patch allows grouping multiple #include blocks together and sort all includes as one big block.
Additionally, sorted includes can be regrouped after sorting based on configured categories.
Contributed by @KrzysztofKapusta!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D40288
llvm-svn: 319024
Summary:
clang-format does not collapse short records, interfaces, unions, etc.,
but fails to do so if the record is preceded by certain modifiers
(export, default, abstract, declare). This change skips over all
modifiers, and thus handles all record definitions uniformly.
Before:
export class Foo { bar: string; }
class Baz {
bam: string;
}
After:
export class Foo {
bar: string;
}
class Baz {
bam: string;
}
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D40430
llvm-svn: 318976
Summary:
TypeScript generic type arguments can contain object (literal) types,
which in turn can contain semicolons:
const x: Array<{a: number; b: string;} = [];
Previously, clang-format would incorrectly categorize the braced list as
a block and terminate the line at the openening `{`, and then format the
entire expression badly.
With this change, clang-format recognizes `<` preceding a `{` as
introducing a type expression. In JS, `<` comparison with an object
literal can never be true, so the chance of introducing false positives
here is very low.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D40424
llvm-svn: 318975
Summary:
Automatic Semicolon Insertion in clang-format tries to guess if a line
wrap should insert an implicit semicolong. The previous heuristic would
not trigger ASI if a token was immediately preceded by an `@` sign:
function foo(@Bar // <-- does not trigger due to preceding @
baz) {}
However decorators can have arbitrary parameters:
function foo(@Bar(param, param, param) // <-- precending @ missed
baz) {}
While it would be possible to precisely find the matching `@`, just
conversatively disabling ASI for the entire line is simpler, while also
not regressing ASI substatially.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D40410
llvm-svn: 318973
Summary:
Wrapping between the type name and the array type indicator creates
invalid syntax in TypeScript.
Before:
const xIsALongIdent:
YJustBarelyFitsLinex
[]; // illegal syntax.
After:
const xIsALongIdent:
YJustBarelyFitsLinex[];
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D40436
llvm-svn: 318959
Summary: The same rules apply as for `return`.
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D40431
llvm-svn: 318958
Summary:
Previously, clang-format would drop a space character between `of` and
then following (non-identifier) token if the preceding token was part of
a destructuring assignment (`}` or `]`).
Before:
for (const [a, b] of[]) {}
After:
for (const [a, b] of []) {}
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D40411
llvm-svn: 318942
Summary:
clang-format already removes empty lines at the beginning & end of
blocks:
int x() {
foo(); // lines before and after will be removed.
}
However because lamdas and arrow functions are parsed as expressions,
the existing logic to remove empty lines in UnwrappedLineFormatter
doesn't handle them.
This change special cases arrow functions in ContinuationIndenter to
remove empty lines:
x = []() {
foo(); // lines before and after will now be removed.
};
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D40178
llvm-svn: 318537
For each line that we break in a protruding token, compute whether the
penalty of breaking is actually larger than the penalty of the excess
characters. Only break if that is the case.
llvm-svn: 318515
Create more orthogonal pieces. The restructuring made it easy to try out
several alternatives to D33589, and while none of the alternatives
turned out to be the right solution, the underlying simplification of
the structure is helpful.
Differential Revision: https://reviews.llvm.org/D39900
llvm-svn: 318141
Summary: This patch adds support for python-style comments in text protos.
Reviewers: djasper
Reviewed By: djasper
Subscribers: bkramer, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D39806
llvm-svn: 317886
Summary:
This makes clang-format sort using declarations case-sensitive with the
exception that '_' comes just before 'A'. This is better than the current case
insensitive version, because it groups uppercase names in the same namespace
together.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D39549
llvm-svn: 317325
Summary:
This patch enables sorting the full block of using declarations when
some line is affected.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D39024
llvm-svn: 316130
Summary:
This patch enables `BreakableToken` to manage the formatting of non-trailing
block comments. It is a refinement of https://reviews.llvm.org/D37007.
We discovered that the optimizer outsmarts us on cases where breaking the comment
costs considerably less than breaking after the comment. This patch addresses
this by ensuring that a newline is inserted between a block comment and the next
token.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D37695
llvm-svn: 315893
Summary:
This patch fixes a regression introduced in r312904, where the formatter confuses
the `else` in `#else` with an `else` of an `if-else` statement.
For example, formatting this code with google style
```
#ifdef A
int f() {}
#else
int f() {}
#endif
```
resulted in
```
#ifdef A
int f() {}
#else
int f() {
}
#endif
```
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37973
llvm-svn: 314683
https://reviews.llvm.org/rL299952 merged '>>>' tokens into a single
JavaRightLogicalShift token. This broke formatting of generics nested more than
two deep, e.g. Foo<Bar<Baz>>> because the '>>>' now weren't three '>' for
parseAngle().
Luckily, just deleting JavaRightLogicalShift fixes things without breaking the
test added in r299952, so do that.
https://reviews.llvm.org/D38291
llvm-svn: 314325
Summary:
NamespaceEndCommentsFixer did not fix namespace comments when the brace opening the namespace was not on the same line as the "namespace" keyword.
It occurs in Allman, GNU and Linux styles and whenever BraceWrapping.AfterNamespace is true.
Before:
```lang=cpp
namespace a
{
void f();
void g();
}
```
After:
```lang=cpp
namespace a
{
void f();
void g();
} // namespace a
```
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37904
llvm-svn: 314279
Keep space before or after the &/&& tokens, but not both. For example,
auto [x,y] = a;
auto &[xr, yr] = a; // LLVM style
auto& [xr, yr] = a; // google style
Differential Revision:https://reviews.llvm.org/D35743
llvm-svn: 314264
Summary:
This ignores case while sorting using-declarations, fixing a case where `_` would appear between lowercase and uppercase characters.
It also applies stable sort, so that replacements for the exact same using declarations are not generated.
Reviewers: klimek, alexfh
Reviewed By: alexfh
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37263
llvm-svn: 313963
Correctly determine when [ is part of a structured binding instead of a
lambda.
To be able to reuse the implementation already available, this patch also:
- sets the Previous link of FormatTokens in the UnwrappedLineParser
- moves the isCppStructuredBinding function into FormatToken
Before:
auto const const &&[x, y] { A *i };
After:
auto const const && [x, y]{A * i};
Fixing formatting of the type of the structured binding is still missing.
llvm-svn: 313742
Most of the work was already done when we introduced a look-behind based
lambda introducer detection.
This patch finishes the transition by completely relying on the simple
lambda introducer detection and simply recursing into normal
brace-parsing code to parse until the end of the introducer.
This fixes initializers in lambdas, including nested lambdas.
Before:
auto a = [b = [c = 42]{}]{};
auto b = [c = &i + 23]{};
After:
auto a = [b = [c = 42] {}] {};
auto b = [c = &i + 23] {};
llvm-svn: 313622
Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **"extern C part"**
**Problem:**
Due to the lack of "brace wrapping extern" flag, clang format does parse the block after **extern** keyword moving the opening bracket to the header line always!
**Patch description:**
A new style added, new configuration flag - **BraceWrapping.AfterExternBlock** that allows us to decide whether we want a break before brace or not.
Reviewers: djasper, krasimir
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37845
Contributed by @PriMee!
llvm-svn: 313354
Summary:
While `goog.setTestOnly` usually appears in the imports section of a file, it is
not actually an import, and also usually doesn't take long parameters (nor
namespaces as a parameter, it's a description/message that should be wrapped).
This fixes a regression where a `goog.setTestOnly` call nested in a function was
not wrapped.
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D37685
llvm-svn: 312918
Summary:
**Short overview:**
Fixed bug: https://bugs.llvm.org/show_bug.cgi?id=34001
Clang-format bug resulting in a strange behavior of control statements short blocks. Different flags combinations do not guarantee expected result. Turned on option AllowShortBlocksOnASingleLine does not work as intended.
**Description of the problem:**
Cpp source file UnwrappedLineFormatter does not handle AllowShortBlocksOnASingleLine flag as it should. Putting a single-line control statement without any braces, clang-format works as expected (depending on AllowShortIfStatementOnASingleLine or AllowShortLoopsOnASingleLine value). Putting a single-line control statement in braces, we can observe strange and incorrect behavior.
Our short block is intercepted by tryFitMultipleLinesInOne function. The function returns a number of lines to be merged. Unfortunately, our control statement block is not covered properly. There are several if-return statements, but none of them handles our block. A block is identified by the line first token and by left and right braces. A function block works as expected, there is such an if-return statement doing proper job. A control statement block, from the other hand, falls into strange conditional construct, which depends on BraceWrapping.AfterFunction flag (with condition that the line’s last token is left brace, what is possible in our case) or goes even further. That should definitely not happen.
**Description of the patch:**
By adding three different if statements, we guarantee that our short control statement block, however it looks like (different brace wrapping flags may be turned on), is handled properly and does not fall into wrong conditional construct. Depending on appropriate options we return either 0 (when something disturbs our merging attempt) or let another function (tryMergeSimpleBlock) take the responsibility of returned result (number of merged lines). Nevertheless, one more correction is required in mentioned tryMergeSimpleBlock function. The function, previously, returned either 0 or 2. The problem was that this did not handle the case when our block had the left brace in a separate line, not the header one. After change, after adding condition, we return the result compatible with block’s structure. In case of left brace in the header’s line we do everything as before the patch. In case of left brace in a separate line we do the job similar to the one we do in case of a “non-header left brace” function short block. To be precise, we try to merge the block ignoring the header line. Then, if success, we increment our returned result.
**After fix:**
**CONFIG:**
```
AllowShortBlocksOnASingleLine: true
AllowShortIfStatementsOnASingleLine: true
BreakBeforeBraces: Custom
BraceWrapping: {
AfterClass: true, AfterControlStatement: true, AfterEnum: true, AfterFunction: true, AfterNamespace: false, AfterStruct: true, AfterUnion: true, BeforeCatch: true, BeforeElse: true
}
```
**BEFORE:**
```
if (statement) doSomething();
if (statement) { doSomething(); }
if (statement) {
doSomething();
}
if (statement)
{
doSomething();
}
if (statement)
doSomething();
if (statement) {
doSomething1();
doSomething2();
}
```
**AFTER:**
```
if (statement) doSomething();
if (statement) { doSomething(); }
if (statement) { doSomething(); }
if (statement) { doSomething(); }
if (statement) doSomething();
if (statement)
{
doSomething1();
doSomething2();
}
```
Contributed by @PriMee!
Reviewers: krasimir, djasper
Reviewed By: krasimir
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D37140
llvm-svn: 312904
EXPENSIVE_CHECKS enables libstdc++'s library consistency checks, which
includes checking the container passed to std::priority_queue for its
well-formedness. This makes the clang-format memoization too expensive,
so disable it.
(it's a necessary feature of libstdc++'s consistency checks that it
ruins the required scalability of C++ standard library features - so
these workarounds are to be expected if a test ever tries to test
scalability in some way, like this test does)
llvm-svn: 312268
Summary:
This is an implementation for [bug 17362](https://bugs.llvm.org/attachment.cgi?bugid=17362) which adds support for indenting preprocessor statements inside if/ifdef/endif. This takes previous work from fmauch (https://github.com/fmauch/clang/tree/preprocessor_indent) and makes it into a full feature.
The context of this patch is that I'm a VMware intern, and I implemented this because VMware needs the feature. As such, some decisions were made based on what VMware wants, and I would appreciate suggestions on expanding this if necessary to use-cases other people may want.
This adds a new enum config option, `IndentPPDirectives`. Values are:
* `PPDIS_None` (in config: `None`):
```
#if FOO
#if BAR
#include <foo>
#endif
#endif
```
* `PPDIS_AfterHash` (in config: `AfterHash`):
```
#if FOO
# if BAR
# include <foo>
# endif
#endif
```
This is meant to work whether spaces or tabs are used for indentation. Preprocessor indentation is independent of indentation for non-preprocessor lines.
Preprocessor indentation also attempts to ignore include guards with the checks:
1. Include guards cover the entire file
2. Include guards don't have `#else`
3. Include guards begin with
```
#ifndef <var>
#define <var>
```
This patch allows `UnwrappedLineParser::PPBranchLevel` to be decremented to -1 (the initial value is -1) so the variable can be used for indent tracking.
Defects:
* This patch does not handle the case where there's code between the `#ifndef` and `#define` but all other conditions hold. This is because when the #define line is parsed, `UnwrappedLineParser::Lines` doesn't hold the previous code line yet, so we can't detect it. This is out of the scope of this patch.
* This patch does not handle cases where legitimate lines may be outside an include guard. Examples are `#pragma once` and `#pragma GCC diagnostic`, or anything else that does not change the meaning of the file if it's included multiple times.
* This does not detect when there is a single non-preprocessor line in front of an include-guard-like structure where other conditions hold because `ScopedLineState` hides the line.
* Preprocessor indentation throws off `TokenAnnotator::setCommentLineLevels` so the indentation of comments immediately before indented preprocessor lines is toggled on each run. Fixing this issue appears to be a major change and too much complexity for this patch.
Contributed by @euhlmann!
Reviewers: djasper, klimek, krasimir
Reviewed By: djasper, krasimir
Subscribers: krasimir, mzeren-vmw, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D35955
llvm-svn: 312125
Summary:
This patch detects the leading '<' in likely xml files and stops formatting in
that case. A recent use of a Qt xml file with a .ts extension triggered this:
http://doc.qt.io/qt-4.8/linguist-ts-file-format.html
Reviewers: djasper
Reviewed By: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D37136
llvm-svn: 311999
Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **Typedef enum part**
**Problem:**
Clang format does not allow the flag **BraceWrapping.AfterEnum** control the case when our **enum** is preceded by **typedef** keyword (what is common in C language).
**Patch description:**
Added case to the **"AfterEnum"** flag when our enum does not start a line - is preceded by **typedef** keyword.
**After fix:**
**CONFIG:**
```
BreakBeforeBraces: Custom
BraceWrapping: {
AfterClass: true, AfterControlStatement: true, AfterEnum: true, AfterFunction: true, AfterNamespace: false, AfterStruct: true, AfterUnion: true, BeforeCatch: true, BeforeElse: true
}
```
**BEFORE:**
```
typedef enum
{
a,
b,
c
} SomeEnum;
```
**AFTER:**
```
typedef enum
{
a,
b,
c
} SomeEnum;
```
Contributed by @PriMee!
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D37143
llvm-svn: 311998
Summary:
Previously, clang-format would try to wrap template string substitutions
by indenting relative to the openening `${`. This helped with
indenting structured strings, such as strings containing HTML, as the
substitutions would be aligned according to the structure of the string.
However it turns out that the overwhelming majority of template string +
substitution usages are for substitutions into non-structured strings,
e.g. URLs or just plain messages. For these situations, clang-format
would often produce very ugly indents, in particular for strings
containing no line breaks:
return `<a href='http://google3/${file}?l=${row}'>${file}</a>(${
row
},${
col
}): `;
This change makes clang-format indent template string substitutions as
if they were string concatenation operations. It wraps +4 on overlong
lines and keeps all operands on the same line:
return `<a href='http://google3/${file}?l=${row}'>${file}</a>(${
row},${col}): `;
While this breaks some lexical continuity between the `${` and `row}`
here, the overall effects are still a huge improvement, and users can
still manually break the string using `+` if desired.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D37142
llvm-svn: 311988
alignments
Indent should be compared before nesting level to determine if a token
is on the same scope as the one we align with. Because it was inverted,
clang-format sometimes tried to align tokens with tokens from outer
scopes, causing the assert(Shift >= 0) to fire.
This fixes bug #33507. Patch by Beren Minor, thank you!
llvm-svn: 311792
Summary:
This recommits https://reviews.llvm.org/D36956 with an update to the added test
case to not use raw string literals, since this makes gcc unhappy.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D37109
llvm-svn: 311672
This reverts commit r311457. It reveals some dormant bugs in comment
reflowing, like breaking a single line jsdoc type annotation before a
parameter into multiple lines.
llvm-svn: 311641
Summary:
This patch makes the splits emitted for the beginning of comment lines during
reformatting absolute. Previously, they were relative to the start of the
non-whitespace content of the line, which messes up further TailOffset
calculations in breakProtrudingToken. This fixes an assertion failure reported
in bug 34236: https://bugs.llvm.org/show_bug.cgi?id=34236.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36956
llvm-svn: 311559
Summary:
ColumnLimit = 0 means no limit, so comment should always be aligned if requested. This was broken with
https://llvm.org/svn/llvm-project/cfe/trunk@304687
introduced via
https://reviews.llvm.org/D33830
and is included in 5.0.0-rc2. This commit fixes it and adds a unittest for this property.
Should go into clang-5.0 IMHO.
Contributed by @pboettch!
Reviewers: djasper, krasimir
Reviewed By: djasper, krasimir
Subscribers: hans, klimek
Differential Revision: https://reviews.llvm.org/D36967
llvm-svn: 311532
Summary:
This patch is an alternative to https://reviews.llvm.org/D36614, by resolving a
non-idempotency issue by breaking non-trailing comments:
Consider formatting the following code with column limit at `V`:
```
V
const /* comment comment */ A = B;
```
The comment is not a trailing comment, breaking before it doesn't bring it under
the column limit. The formatter breaks after it, resulting in:
```
V
const /* comment comment */
A = B;
```
For a next reformat, the formatter considers the comment as a trailing comment,
so it is free to break it further, resulting in:
```
V
const /* comment
comment */
A = B;
```
This patch improves the situation by directly producing the third case.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D37007
llvm-svn: 311457
Summary:
clang-format wraps object literal keys in an object literal if they are
marked as `TT_SelectorName`s and/or the colon is marked as
`TT_DictLiteral`. Previously, clang-format would accidentally work
because colons in type aliases were marked as `TT_DictLiteral`. r310367
fixed this to assing `TT_JsTypeColon`, which broke wrapping in certain
situations. However the root cause was that clang-format incorrectly
didn't skip questionmarks when detecting selector name.
This change fixes both locations to (1) assign `TT_SelectorName` and (2)
treat `TT_JsTypeColon` like `TT_DictLiteral`.
Previously:
type X = {
a: string, b?: string,
};
Now:
type X = {
a: string,
b?: string,
};
Reviewers: djasper, sammccall
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D36684
llvm-svn: 310852
Summary:
In JavaScript, may keywords can be used in method names and thus call sites:
foo.delete();
foo.instanceof();
clang-format would previously insert whitespace after the `instanceof`. This
change generically skips inserting whitespace between a keyword and a
parenthesis if preceded by a dot, i.e. in a callsite.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36142
llvm-svn: 310851
Summary: The original changes for ref qualifiers in rL272537 and rL272548 allowed function const+ref qualifier spacing to diverge from the spacing used for variables. It seems more consistent for `T const& x;` to match `void foo() const&;`.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34324
llvm-svn: 310544
This fixes a bug in `ENAS_DontAlign` (introduced in D32733) where blank lines had an EscapedNewlineColumn of 0, causing a subtraction to overflow when converted back to unsigned and leading to runaway memory allocation.
Differential Revision: https://reviews.llvm.org/D36019
llvm-svn: 310539
Summary: A closing parenthesis followed by a declaration or statement should always terminate the current statement.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36491
llvm-svn: 310482
Summary:
This handles a case where the trailing '*/' of a multiline jsdoc eding in a
comment pragma wouldn't be put on a new line.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D36359
llvm-svn: 310458
Summary:
Previously, clang-format would insert whitespace in union types nested in object
and array types, as it wouldn't recognize those as a type operator:
const x: {foo: number | null};
const x: [number | null];
While this is correct for actual binary operators, clang-format should not
insert whitespace into union and intersection types to mark those:
const x: {foo: number|null};
const x: [number|null];
This change propagates that the context is not an expression by inspecting
the preceding token and marking as non-expression if it was a type colon.
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D36136
llvm-svn: 310367
Summary:
Previously, clang-format would consider the following code line to be part of
the comment and incorrectly format the rest of the file.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36159
llvm-svn: 310365
Summary:
`case:` and `default:` would normally parse as labels for a `switch` block.
However in TypeScript, they can be used in field declarations, e.g.:
interface I {
case: string;
}
This change special cases parsing them in declaration lines to avoid wrapping
them.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36148
llvm-svn: 310070
Summary:
This patch fixes the indentation of the code pattern `key <...>`and `key {...}` in text protos.
Previously, such line would be alinged depending on the column of the previous
colon, which usually indents too much.
I'm gonna go ahead and commit this since it's a straightforward bugfix.
Reviewers: djasper, klimek
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36143
llvm-svn: 309941
Summary:
This patch fixes the parsing of proto option fields like `option op = <...>`.
Previously the parser did not enter the right code path inside the angle braces,
causing the contents to be split into several unwrapped lines inside.
I'll just go ahead and commit this since it's a straightforward bugfix.
Reviewers: djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D36217
llvm-svn: 309937
Summary: `throw (...)` should have a whitespace following it, as do await and void.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36146
llvm-svn: 309710
Summary: clang-format would previously fail to detect that an arrow functions parameter block is not an expression, and thus insert whitespace around the `|` and `&` type operators in it.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36147
llvm-svn: 309707
Summary: Previously, const enums would get formatted differently because the modifier was not recognized.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36144
llvm-svn: 309703
Summary: Formerly, `import {default as X} from y;` would not be recognized as an import.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36132
llvm-svn: 309697
Summary:
clang-format would previously drop the whitespace after `extends` in code such as:
class Foo extends {} {}
Where the first set of curly braces is an inline object literal type.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36131
llvm-svn: 309695
Summary:
Allow merging short case labels when they actually end with a comment
(like a comment after the ``break``) and when followed by switch-level
comments (e.g. aligned with next case):
switch(a) {
case 0: break; // comment at end of case
case 1: return value;
// comment related to next case
// comment related to next case
case 2:
}
Reviewers: krasimir, djasper
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35557
llvm-svn: 309370
Summary:
The current code would return an incorrect value when a preprocessor
directive is present immediately after the opening brace: this causes
the nanespace end comment fixer to break in some places, for exemple it
would not add the comment in this case:
namespace a {
#define FOO
}
Fixing the computation is simple enough, but it was breaking a feature,
as it would cause comments to be added also when the namespace
declaration was dependant on conditional compilation.
To fix this, a hash of the current preprocessor stack/branches is
computed at the beginning of parseBlock(), so that we explicitely do not
store the OpeningLineIndex when the beginning and end of the block are
not in the same preprocessor conditions.
Tthe hash is computed based on the line, but this could propbably be
improved by using the actual condition, so that clang-format would be
able to match multiple identical #ifdef blocks.
Reviewers: krasimir, djasper
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35483
llvm-svn: 309369
Summary:
This fixes a regression exposed by r307795 and rL308725 in which the level of a
comment line between '} else {' and a preprocessor directive is incorrectly set
as the level of the '} else {' line. For example, this :
```
int f(int i) {
if (i) {
++i;
} else {
// comment
#ifdef A
--i;
#endif
}
}
```
was formatted as:
```
int f(int i) {
if (i) {
++i;
} else {
// comment
#ifdef A
--i;
#endif
}
}
```
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35794
llvm-svn: 308882
Summary:
This fixes a regression exposed by r307795 in which the level of a comment line
between '}' and a preprocessor directive is incorrectly set as the level of the
line before the '}'. In effect, this:
```
int f(int i) {
int j = i;
return i + j;
}
// comment
#ifdef A
#endif
```
was formatted as:
```
int f(int i) {
int j = i;
return i + j;
}
// comment
#ifdef A
#endif
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D35485
llvm-svn: 308725
Currently the `UnwrappedLineParser` fails to correctly unwrap JavaScript
imports where the module path is not on the same line as the `from` keyword.
For example:
import {A} from
'some/path/longer/than/column/limit/module.js';```
This causes issues when in the middle a list of imports because the formatter
thinks it has reached the end of the imports, and therefore will not sort any
imports lower in the list.
The formatter will, however, split the `from` keyword and the module path if
the path exceeds the column limit, which triggers the issue the next time the
file is formatted.
Patch originally by Jared Neil - thanks!
Differential Revision: https://reviews.llvm.org/D34920
llvm-svn: 308306
The goal of this commit is to fix clang-format so it does not merge tokens when
using the alternative spelling keywords. (eg: "not foo" should not become "notfoo")
The problem is that Preprocessor::HandleIdentifier used to drop the identifier info
from the token for these keyword. This means the first condition of
TokenAnnotator::spaceRequiredBefore is not met. We could add explicit check for
the spelling in that condition, but I think it is better to keep the IdentifierInfo
and handle the operator keyword explicitly when needed. That actually leads to simpler
code, and probably slightly more efficient as well.
Another side effect of this change is that __identifier(and) will now work as
one would expect, removing a FIXME from the MicrosoftExtensions.cpp test
Differential Revision: https://reviews.llvm.org/D35172
llvm-svn: 308008
Summary:
This patch fixes bug https://bugs.llvm.org/show_bug.cgi?id=3313: a comment line
was aligned with the next #ifdef even in the presence of an empty line between
them.
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35296
llvm-svn: 307795
Summary:
This patch updates the formatting of message fields of type `a{...}` to `a {...}`
for proto messages.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35015
llvm-svn: 307261
Summary:
This patch introduces a few extra BraceWrapping options, similar to
`SplitEmptyFunction`, to allow merging empty 'record' bodies (e.g.
class, struct, union and namespace):
* SplitEmptyClass
* SplitEmptyStruct
* SplitEmptyUnion
* SplitEmptyNamespace
The `SplitEmptyFunction` option name has also been simplified/
shortened (from `SplitEmptyFunctionBody`).
These options are helpful when the correspond AfterXXX option is
enabled, to allow merging the empty record:
class Foo
{};
In addition, this fixes an unexpected merging of short records, when
the AfterXXXX options are used, which caused to be formatted like
this:
class Foo
{ void Foo(); };
This is now properly formatted as:
class Foo
{
void Foo();
};
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34395
llvm-svn: 306874
Summary:
This patch tries to avoid binpacking when initializing lists/arrays, to allow things like:
static int types[] = {
registerType1(),
registerType2(),
registerType3(),
};
std::map<int, std::string> x = {
{ 0, "foo fjakfjaklf kljj" },
{ 1, "bar fjakfjaklf kljj" },
{ 2, "stuff fjakfjaklf kljj" },
};
This is similar to how dictionnaries are formatted, and actually corresponds to the same conditions: when initializing a container (and not just 'calling' a constructor).
Such formatting involves 2 things:
* Line breaks around the content of the block. This can be forced by adding a comma or comment after the last element
* Elements should not be binpacked
This patch considers the block is an initializer list if it either ends with a comma, or follows an assignment, which seems to provide a sensible approximation.
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: malcolm.parsons, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34238
llvm-svn: 306868
improve support for LLVM-style include sorting.
This really is a collection of improvements to the rules for LLVM
include sorting:
- We have gmock headers now, so it adds support for those to one of the
categories.
- LLVM does use 'FooTest.cpp' files to test 'Foo.h' so it adds that
suffix for finding a main header.
- At times the test file's case may not match the header file's case, so
switch to case-insensitive regex matching of header names.
With this set of changes, I can't spot any misbehaviors when re-sorting
all of LLVM's unittest '#include' lines.
Thanks to Eric and Daniel for help testing and refining the patch during
review!
Differential Revision: https://reviews.llvm.org/D33932
llvm-svn: 306759
Summary:
This patch makes the `{` in `msg_field{field: OK}` in a proto option scope be
treated as an assignment operator. Previosly the added test case was formatted
as:
```
option (MyProto.options) = {
field_a: OK
field_b{field_c: OK} field_d: OKOKOK field_e: OK
}
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34749
llvm-svn: 306672
Summary:
This patch adds support for <>-style proto message fields inside proto options.
Previously these were wrongly treated as binary operators and as such were
working only by chance for a limited number of cases.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34621
llvm-svn: 306406
Summary:
This is the same as Inline, except it does not imply all empty
functions are merged: with this style, empty functions are merged only
if they also match the 'inline' criteria (i.e. defined in a class).
This is helpful to avoid inlining functions in implementations files.
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: klimek, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D34399
llvm-svn: 305912
Summary:
This fixes the missing space before the designated initializer when `Cpp11BracedListStyle=false` :
const struct A a = { .a = 1, .b = 2 };
^
Also, wrapping between opening brace and designated array initializers used to have an excessive penalty (like breaking between an expression and the subscript operator), leading to unexpected wrapping:
const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa =
{[1] = aaaaaaaaaaaaaaaaaaaaaaaaaaa,
[2] = bbbbbbbbbbbbbbbbbbbbbbbbbbb};
instead of:
const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa = {
[1] = aaaaaaaaaaaaaaaaaaaaaaaaaaa,
[2] = bbbbbbbbbbbbbbbbbbbbbbbbbbb};
Finally, designated array initializers are not binpacked, just like designated member initializers.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, krasimir, klimek
Differential Revision: https://reviews.llvm.org/D33491
llvm-svn: 305696
Fixes an issue where struct A { int X; }; would be broken onto multiple
lines, but typedef struct A { int X; } A2; was collapsed onto a single
line.
Patch by Jacob Bandes-Storch. Thank you.
llvm-svn: 305667
c++1z adds the following constructions to the language:
if constexpr (cond)
statement1;
else if constexpr (cond)
statement2;
else if constexpr (cond)
statement3;
else
statement4;
A first version of this was proposed in reviews.llvm.org/D26953 by
Francis Visoiu Mistrih, but never commited. This patch additionally
fixes the behavior when allowing short if statements on a single line
and was authored by Jacob Bandes-Storch. Thank you to both authors.
llvm-svn: 305666
Summary:
Add CompactNamespaces option, to pack namespace declarations on the
same line (somewhat similar to C++17 nested namespace definition).
With this option, consecutive namespace declarations are kept on the
same line:
namespace foo { namespace bar {
...
}} // namespace foo::bar
Reviewers: krasimir, djasper, klimek
Reviewed By: djasper
Subscribers: kimgr, cfe-commits, klimek
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32480
llvm-svn: 305384
Summary:
This option supplements the AllowShortFunctionsOnASingleLine flag, to
merge empty function body at the beginning of the line: e.g. when the
function is not short-enough and breaking braces after function.
int f()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33447
llvm-svn: 305272
Summary:
This patch is a follow-up of https://reviews.llvm.org/rL304687, which fixed an
overflow in the comment alignment code in clang-format. The token length of
trailing comments of preprocessor directives is calculated incorrectly by
including the text between consecutive directives. That causes them to not being
aligned.
For example, in this code with column limit 20
```
#if A
#else // A
int iiii;
#endif // B
```
the length of the token `// A` was wrongly calculated as 14 = 5 (the size of `// A\n`) plus 9 (the size of `int iiii;`) and so `// A` wouldn't be aligned with `// B` and this was produced:
```
#if A
#else // A
int iiii;
#endif // B
```
This patch fixes this case.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33982
llvm-svn: 304912
Summary: Support "export type T = {...};", in addition to just "type T = {...};".
Reviewers: klimek
Differential Revision: https://reviews.llvm.org/D33980
llvm-svn: 304904
Nested literals are sometimes only indented by 2 spaces, instead of
respecting the IndentWidth option.
There are existing unit tests (FormatTestJS.ArrayLiterals) that only
pass because the style used to test them uses an IndentWidth of 2.
This change removes the magic 2 and always uses the IndentWidth.
I've added 6 tests. The first 4 of these tests fail before this change,
while the last 2 already pass, but were added just to make sure it the
change works with all types of braces.
Patch originally by Jared Neil, thanks!
Differential Revision: https://reviews.llvm.org/D33857
llvm-svn: 304791
Summary:
This patch fixes a bug where clang-format will align newly broken trailing
comments even if this will make them exceed the line limit. The bug was caused
by a combination of unsigned arithmetic overflow and an imprecise computation
of the length of broken comment lines.
Reviewers: djasper, alexfh
Reviewed By: alexfh
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33830
llvm-svn: 304687
Summary:
calculateBraceTypes decides for braced init for empty brace pairs ({}).
In context of a function declaration, this incorrectly classifies empty
function or method bodies as braced inits, leading to missing wraps:
class C {
foo() {}[bar]() {}
}
Where code should have wrapped after "}", before "[". This change adds
another piece of contextual information in that braces following closing
parentheses must always be the opening braces of function blocks. This
fixes brace detection for methods immediately followed by brackets
(computed property declarations), but also curlies.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33714
llvm-svn: 304290
Summary:
In JavaScript, duplicated commas have semantic meaning.
x = [a,,b];
The statement above creates an array with three entries, the middle being undefined. Because clang-format should not change semantics, disable this cleanup in JS.
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33641
llvm-svn: 304141
Summary:
The previous fix to force build style wrapping if the previous token is a closing parenthesis broke a peculiar pattern where users parenthesize the function declaration in a bind call:
fn((function() { ... }).bind(this));
This restores the previous behaviour by reverting that change, but narrowing the special case for unindenting closing parentheses to those followed by semicolons and opening braces, i.e. immediate calls and function declarations.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33640
llvm-svn: 304135
Summary:
This option replaces the BreakConstructorInitializersBeforeComma option with an enum, thus introducing a mode where the colon stays on the same line as constructor declaration:
// When it fits on line:
Constructor() : initializer1(), initializer2() {}
// When it does not fit:
Constructor() :
initializer1(), initializer2()
{}
// When ConstructorInitializerAllOnOneLineOrOnePerLine = true:
Constructor() :
initializer1(),
initializer2()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32479
llvm-svn: 303739
The change that enabled wrapping at the previous scope's indentation had
unintended side-effects in that clang-format would prefer to wrap
closing parentheses to the next line if it avoided a wrap on the next
line (assuming very narrow lines):
fooObject
.someCall(barbazbam)
.then(bam);
Would get formatted as:
fooObject.someCall(barbazbam
).then(bam);
Because the ')' is now indented at the parent level (fooObject).
Normally formatting a builder pattern style call sequence like that is
outlawed in clang-format anyway. However for JavaScript this is special
cased to support trailing .bind calls.
This change disallows this special case when following a closing ')' to
avoid the problem.
Included are some random comment fixes.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33399
llvm-svn: 303557
Summary:
This patch prevents reflowing bullet lists in block comments.
It handles all lists supported by doxygen and markdown, e.g. bullet
lists starting with '-', '*', '+', as well as numbered lists starting
with -# or a number followed by a dot.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33285
llvm-svn: 303556
Summary:
r303415 changed the way a sequence of line comments following a preprocessor
macro is handled, which has the unfortunate effect of aligning a trailing
preprocessor line comment and following unrelated section comments, so:
```
#ifdef A // comment about A
// section comment
#endif
```
gets turned into:
```
#ifdef A // comment about A
// section comment
#endif
```
This patch fixes this by additionally checking the original start columns of
the line comments.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33394
llvm-svn: 303541
Summary:
Add option to customize the penalty for breaking assignment
This allows increasing the priority of the assignment, to prefer spliting
an operation instead of splitting the assignment, e.g. :
int a = bbbbbbbbbbbbbbbb +
cccccccccccccccc;
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32477
llvm-svn: 303534
Summary:
This patch updates the handling of multiline trailing comment sections in
import statement lines to make it more consistent with the case in general.
This includes updating the parsing logic to collect the trailing comment
sections and the formatting logic to not insert escaped newlines at the end of
comment lines in import statement lines.
Specifically, before this patch this code:
```
#include <a> // line 1
// line 2
```
will be turned into two unwrapped lines, whereas this code:
```
int i; // line 1
// line 2
```
is turned into a single unwrapped line, enabling reflowing across comments.
An example where the old behaviour is bad is when partially formatting the lines
3 to 4 of this code:
```
#include <a> // line 1
// line 2
int i;
```
which gets turned into:
```
#include <a> // line 1
// line 2
int i;
```
because the two comment lines were independent and the indent was copied.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33351
llvm-svn: 303415
Summary:
The syntax is actually `for await (const x of y)` (d'oh).
This also fixes a crash for `for` tokens not followed by additional tokens.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33329
llvm-svn: 303382
Summary:
Doxygen supports putting documentation blocks after member, by adding
an additional < marker in the comment block. This patch makes sure
this marker is used in lines which are introduced by breaking the
comment.
int foo; ///< Some very long comment.
becomes:
int foo; ///< Some very long
///< comment.
Contributed by @Typz!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33282
llvm-svn: 303330
myFunction(param1, param2,);
For symmetry with other parenthesized lists ([...], {...}), clang-format should
wrap parenthesized lists one-per-line if they contain a trailing comma:
myFunction(
param1,
param2,
);
This is particularly useful in function declarations or calls with many
arguments, e.g. commonly in constructors.
Differential Revision: https://reviews.llvm.org/D33023
llvm-svn: 303049
Summary:
`getIdentifierInfo()` includes all keywords, whereas non-null assertion
operators should only be recognized after non-keywords or pseudo keywords.
Ideally this should list all tokens that clang-format recognizes as a keyword,
but that are pseudo or no keywords in JS. For the time being, just recognize
the specific bits users ran into (`namespace` in this case).
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33182
llvm-svn: 303038
Summary:
For C++ code, opening parenthesis following a } indicate a braced init. For JavaScript and other languages, this is an invalid syntactical construct, unless the closing parenthesis belongs to a function - in which situation its a BK_Block.
This fixes indenting IIFEs following top level functions:
function foo() {}
(function() { codeHere(); }());
clang-format used to collapse these lines together.
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33006
llvm-svn: 302658
Because IIFEs[1] are often used like an anonymous namespace around large
sections of JavaScript code, it's useful not to indent to them (which
effectively reduces the column limit by the indent amount needlessly).
It's also common for developers to wrap these around entire files or
libraries. When adopting clang-format, changing the indent entire file
can reduce the usefulness of the blame annotations.
Patch by danbeam, thanks!
Differential Revision: https://reviews.llvm.org/D32989
llvm-svn: 302580
DontAlign
This converts the clang-format option AlignEscapedNewlinesLeft from a
boolean to an enum, named AlignEscapedNewlines, with options Left (prev.
true), Right (prev. false), and a new option DontAlign.
When set to DontAlign, the backslashes are placed just after the last token in each line:
#define EXAMPLE \
do { \
int x = aaaaa; \
int b; \
int dddddddddd; \
} while (0)
Patch by jtbandes. Thank you!
llvm-svn: 302428
Summary: While its precedence should be higher than multiplicative, LLVM does not have a level for that, so for the time being just treat it as multiplicative.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32864
llvm-svn: 302156
Summary:
Previously, clang-format would accidentally parse an async function
declaration as a function expression, and thus not insert an unwrapped
line for async functions, causing subsequent functions to run into the
function:
async function f() {
x();
} function g() { ...
With this change, async functions get parsed as top level function
declarations and get their own unwrapped line context.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32590
llvm-svn: 301538
Summary:
Java and JavaScript support annotations and decorators, respectively, that use a leading "@" token. clang-format currently detects this as an Objective-C construct and applies special formatting, for example no whitespace around "=" operators. This change disables the distinction for Java and JavaScript, which leads to normal formatting of single line annotated and initialized properties.
Before:
class X {
@foo() bar=false;
}
After:
class X {
@foo() bar = false;
}
Reviewers: djasper, bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32532
llvm-svn: 301399
Summary: In JavaScript/TypeScript, class member definitions that use modifiers can be subject to Automatic Semicolon Insertion (ASI). For example, "class X { get \n foo }" defines a property called "get" and a property called "foo", both with no type annotation. This change prevents wrapping after the modifier keywords (visibility modifiers, static, get and set) to prevent accidental ASI.
Reviewers: djasper, bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32531
llvm-svn: 301397
Before:
std::function<
LoooooooooooongTemplatedType<SomeType>*(
LooooooooooooooooooooongType
type)>
function;
After:
std::function<
LoooooooooooongTemplatedType<
SomeType>*(
LooooooooooooooooongType type)>
function;
clang-format generally avoids having lines like "SomeType>*(" as they
lead to parameter lists that don't belong together to be aligned. However, in
case it is better than the alternative, which can even be violating the column
limit.
llvm-svn: 301182
Summary: This patch replaces the boolean IncompleteFormat that is used to notify the client if an unrecoverable syntax error occurred by a struct that also contains a line number.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32298
llvm-svn: 300985
Previously, if an escaped newline was followed by a newline or a nul, we'd lex
the escaped newline as a bogus space character. This led to a bunch of
different broken corner cases:
For the pattern "\\\n\0#", we would then have a (horizontal) space whose
spelling ends in a newline, and would decide that the '#' is at the start of a
line, and incorrectly start preprocessing a directive in the middle of a
logical source line. If we were already in the middle of a directive, this
would result in our attempting to process multiple directives at the same time!
This resulted in crashes, asserts, and hangs on invalid input, as discovered by
fuzz-testing.
For the pattern "\\\n" at EOF (with an implicit following nul byte), we would
produce a bogus trailing space character with spelling "\\\n". This was mostly
harmless, but would lead to clang-format getting confused and misformatting in
rare cases. We now produce a trailing EOF token with spelling "\\\n",
consistent with our handling for other similar cases -- an escaped newline is
always part of the token containing the next character, if any.
For the pattern "\\\n\n", this was somewhat more benign, but would produce an
extraneous whitespace token to clients who care about preserving whitespace.
However, it turns out that our lexing for line comments was relying on this bug
due to an off-by-one error in its computation of the end of the comment, on the
slow path where the comment might contain escaped newlines.
llvm-svn: 300515
At present, clang-format mangles Java containing logical right shift operators
('>>>=' or '>>>'), splitting them in two, resulting in invalid code:
public class Minimal {
public void func(String args) {
int i = 42;
- i >>>= 1;
+ i >> >= 1;
return i;
}
}
This adds both forms of logical right shift to the FormatTokenLexer, so
clang-format won't attempt to split them and insert bogus whitespace.
https://reviews.llvm.org/D31652
Patch from Richard Bradfield <bradfier@fstab.me>!
llvm-svn: 299952
clang-format <<END
auto c1 = u8'a';
auto c2 = u'a';
END
Before:
auto c1 = u8 'a';
auto c2 = u'a';
Now:
auto c1 = u8'a';
auto c2 = u'a';
Patch from Denis Gladkikh <llvm@denis.gladkikh.email>!
llvm-svn: 299574
Summary:
The new test case was crashing before. Now it passes
as expected.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D31441
llvm-svn: 299465
clang-format treats MSVC `__super` keyword like all other keywords adding
a single space after. This change disables this behavior for `__super`.
Patch originally by jutocz (thanks!).
Differential Revision: https://reviews.llvm.org/D30932
llvm-svn: 297936
This prevents unwanted fallout from r296664. Specifically in proto formatting,
this changed:
optional Aaaaaaaa aaaaaaaa = 12 [
(aaa) = aaaa,
(bbbbbbbbbbbbbbbbbbbbbbbbbb) = {
aaaaaaaaaaaaaaaaa: true,
aaaaaaaaaaaaaaaa: true
}
];
Into:
optional Aaaaaaaa aaaaaaaa = 12 [
(aaa) = aaaa,
(bbbbbbbbbbbbbbbbbbbbbbbbbb) =
{aaaaaaaaaaaaaaaaa: true, aaaaaaaaaaaaaaaa: true}
];
Which is considered less readable. Generally, it seems preferable to
format such dict literals as blocks rather than contract them to one
line.
llvm-svn: 297696
Summary:
@see is special among JSDoc tags in that it is commonly followed by URLs. The JSDoc spec suggests that users should wrap URLs in an additional {@link url...} tag (@see http://usejsdoc.org/tags-see.html), but this is very commonly violated, with @see being followed by a "naked" URL.
This change special cases all JSDoc lines that contain an @see not to be wrapped to account for that.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30883
llvm-svn: 297607
Summary:
Previously clang-format would not break after any !. However in TypeScript, ! can be used as a post fix operator for non-nullability:
x.foo()!.bar()!;
With this change, clang-format will wrap after the ! if it is likely a post-fix non null operator.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30705
llvm-svn: 297606
Summary:
`interface` and `type` are pseudo keywords and cause automatic semicolon
insertion when followed by a line break:
interface // gets parsed as a long variable access to "interface"
VeryLongInterfaceName {
}
With this change, clang-format not longer wraps after `interface` or `type`.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30874
llvm-svn: 297605
Summary:
This patch makes ContinuationIndenter call breakProtrudingToken only if
NoLineBreak and NoLineBreakInOperand is false.
Previously, clang-format required two runs to converge on the following example with 24 columns:
Note that the second operand shouldn't be splitted according to NoLineBreakInOperand, but the
token breaker doesn't take that into account:
```
func(a, "long long long long", c);
```
After first run:
```
func(a, "long long "
"long long",
c);
```
After second run, where NoLineBreakInOperand is taken into account:
```
func(a,
"long long "
"long long",
c);
```
With the patch, clang-format now obtains in one run:
```
func(a,
"long long long"
"long",
c);
```
which is a better token split overall.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30575
llvm-svn: 297274
Summary:
This patch enables comment reflowing of lines not matching the comment pragma regex
in multiline comments containing comment pragma lines. Previously, these comments
were dumped without being reindented to the result.
Reviewers: djasper, mprobst
Reviewed By: mprobst
Subscribers: klimek, mprobst, cfe-commits
Differential Revision: https://reviews.llvm.org/D30697
llvm-svn: 297261
Summary:
This patch adds support for namespaces ending in semicolon to the namespace comment fixer.
source:
```
namespace A {
int i;
int j;
};
```
clang-format before:
```
namespace A {
int i;
int j;
} // namespace A;
```
clang-format after:
```
namespace A {
int i;
int j;
}; // namespace A
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30688
llvm-svn: 297140
Summary:
Until now, NamespaceEndCommentFixer was adding missing comments for every run,
which results in multiple end comments for:
```
namespace {
int i;
int j;
}
#if A
int a = 1;
#else
int a = 2;
#endif
```
result before:
```
namespace {
int i;
int j;
}// namespace // namespace
#if A
int a = 1;
#else
int a = 2;
#endif
```
result after:
```
namespace {
int i;
int j;
}// namespace
#if A
int a = 1;
#else
int a = 2;
#endif
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30659
llvm-svn: 297028
Summary:
This patch makes the namespace comment fixer use the number of unwrapped lines
that a namespace spans to detect it that namespace is short, thus not needing
end comments to be added.
This is needed to ensure clang-format is idempotent. Previously, a short namespace
was detected by the original source code lines. This has the effect of requiring two
runs for this example:
```
namespace { class A; }
```
after first run:
```
namespace {
class A;
}
```
after second run:
```
namespace {
class A;
} // namespace
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30528
llvm-svn: 296736
Many things were wrong:
- We didn't always allow wrapping after "as", which can be necessary.
- We used to Undestand the identifier after "as" as a start of a name.
- We didn't properly parse the structure of the expression with "as"
having the precedence of relational operators
llvm-svn: 296659
Summary:
This patch enables namespace end comments under a new flag FixNamespaceComments,
which is enabled for the LLVM and Google styles.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30405
llvm-svn: 296632
Those blocks are used if C++ code is SWIG-wrapped (see swig.org) and
usually do not contain C++ code. Also cleanup the implementation of for #if 0
and #if false a bit.
llvm-svn: 296605
Summary:
Also limits the blacklisting to only apply when the tag is actually
followed by a parameter in curly braces.
/** @mods {long.type.must.not.wrap} */
vs
/** @const this is a long description that may wrap. */
Reviewers: djasper
Subscribers: klimek, krasimir, cfe-commits
Differential Revision: https://reviews.llvm.org/D30452
llvm-svn: 296467
Summary:
This patch adds a NamespaceEndCommentsFixer TokenAnalyzer for clang-format,
which fixes end namespace comments.
It currently supports inserting and updating existing wrong comments.
Example source:
```
namespace A {
int i;
}
namespace B {
int j;
} // namespace A
```
after formatting:
```
namespace A {
int i;
} // namespace A
namespace B {
int j;
} // namespace B
```
Reviewers: klimek, djasper
Reviewed By: djasper
Subscribers: klimek, mgorny
Differential Revision: https://reviews.llvm.org/D30269
llvm-svn: 296341
Summary:
Async arrow functions should be marked with a whitespace after the async keyword, before the parameter list:
x = async () => foo();
Before:
x = async() => foo();
This makes it easier to tell apart an async arrow function from a call to a function called async.
Reviewers: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30399
llvm-svn: 296330
r289428 added a separate language kind for Objective-C, but kept many
"Language == LK_Cpp" checks untouched. This introduced a "IsCpp()"
method that returns true for both C++ and Objective-C++, and replaces
all comparisons of Language with LK_Cpp with calls to this new method.
Also add a lot more test coverge for formatting things in LK_ObjC mode,
by having FormatTest's verifyFormat() test for LK_ObjC everything that's
being tested for LK_Cpp at the moment.
Fixes PR32060 and many other things.
llvm-svn: 296160
Specifically, similar to other blocks, clang-format now wraps both
after "${" and before the corresponding "}", if the contained
expression spans multiple lines.
llvm-svn: 295663
Before:
var someValue = (v as aaaaaaaaaaaaaaaaaaaa<T>[
]).someFunction(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
var someValue = (v as aaaaaaaaaaaaaaaaaaaa<T>[])
.someFunction(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 295658
This can lead to bad behavior with macros that are used to annotate
functions (e.g. ALWAYS_INLINE).
Before, this:
ALWAYS_INLINE ::std::string getName() ...
was turned into:
ALWAYS_INLINE::std::string getName() ...
If it turns out that clang-format is failing to clean up a lot of the
existing spaces now, we can add more analyses of the identifier. It
should not currently. Cases where clang-format breaks nested name
specifiers should be fine as clang-format wraps after the "::". Thus, a
line getting longer and then shorter again should lead to the same
original code.
llvm-svn: 295437
Summary: With a growing suite of comment-related tests, it makes sense to take them out of the main test file. No functional changes.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek, mgorny
Differential Revision: https://reviews.llvm.org/D29713
llvm-svn: 294439
Summary:
Make the comment alignment respect sections of line comments originally alinged
with the next token. Until now the decision how to break a continuous sequence
of line comments into sections was taken without reference to the next token.
source:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
format before:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
format after:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29626
llvm-svn: 294435
Summary:
In JavaScript, object literals can contain methods:
var x = {
a() { return 1; },
};
Previously, clang-format always parsed nested {} inside a braced list as
further braced lists. Special case this logic for JavaScript to try
parsing as a braced list, but fall back to parsing as a child block.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D29656
llvm-svn: 294315
Summary:
Regex detection would incorrectly classify a trailing `!` operator
(nullability cast) followed by a `/` as the start of a regular
expression literal. This fixes code such as:
var foo = x()! / 10;
Which would previously parse a regexp all the way to the end of the
source file (or next `/`).
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29634
llvm-svn: 294304
Summary:
In JavaScript, classes are expressions, so they can appear e.g. in
argument lists.
var C = foo(class {
bar() {
return 1;
}
};
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29635
llvm-svn: 294302
Fix for the formatting options combination of
BreakBeforeBinaryOperators: All, AlignAfterOpenBracket: AlwaysBreak not
handling long templates correctly. This patch allows a break after an
opening left parenthesis, TemplateOpener, or bracket when both options
are enabled.
Patch by Daphne Pfister, thank you!
Fixes llvm.org/PR30304.
llvm-svn: 294179
Summary:
The comment aligner was skipping over newly broken comment lines. This patch fixes that.
source:
```
int ab; // line
int a; // long long
```
format with column limit 15 before:
```
int ab; // line
int a; // long
// long
```
format with column limit 15 after:
```
int ab; // line
int a; // long
// long
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29486
llvm-svn: 293997
Summary:
The comment reflower wasn't taking comment pragmas as reflow stoppers. This patch fixes that.
source:
```
// long long long long
// IWYU pragma:
```
format with column limit = 20 before:
```
// long long long
// long IWYU pragma:
```
format with column limit = 20 after:
```
// long long long
// long
// IWYU pragma:
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29450
llvm-svn: 293898
Summary:
The breaking of line comment sections was misaligning the case where the first comment line is on an unwrapped line containing newlines. In this case, the breaking column must be based on the source column of the last token that is preceded by a newline, not on the first token of the unwrapped line.
source:
```
enum A {
a, // line 1
// line 2
};
```
format before:
```
enum A {
a, // line 1
// line 2
};
```
format after:
```
enum A {
a, // line 1
// line 2
};
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29444
llvm-svn: 293891
Without alignment, there is no clean separation between the arguments, even if
there are only two.
Before:
aaaaaaaaaaaaaa(
aaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaa(aaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 293875
Summary:
Comment reflower was adding untouchable tokens in case two consecutive comment lines are aligned in the source code. This disallows the whitespace manager to re-indent them later.
source:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
Since line 2 and line 3 are aligned, the reflower was marking line 3 as untouchable; however the three comment lines need to be re-aligned.
output before:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
output after:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29383
llvm-svn: 293755
This rows back on r288120, r291801 and r292110. I apologize in advance
for the churn. All of those revisions where meant to make the wrapping
of RHS expressions more consistent. However, now that they are
consistent, we seem to be a bit too eager.
The reasoning here is that I think it is generally correct that we want
to line-wrap before multiline RHS expressions (or multiline arguments to
a function call). However, if there are only two of such operands or
arguments, there is always a clear vertical separation between them and
the additional line break seems much less desirable.
Somewhat good examples are expressions like:
EXPECT_EQ(2, someLongExpression(
orCall));
llvm-svn: 293752
Summary:
The reflower didn't measure precisely the line column of a line in the middle of
a line comment section that has a prefix that needs to be adapted.
source:
```
/// a
//b
```
format before:
```
/// a
//b
```
format after:
```
/// a
// b
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29329
llvm-svn: 293641
This only affects expressions inside ${} scopes of template strings.
Here, we want to indent relative to the surrounding template string and
not the surrounding expression. Otherwise, this can create quite a mess.
Before:
var f = `
aaaaaaaaaaaaaaaaaa: ${someFunction(
aaaaa + //
bbbb)}`;
After:
var f = `
aaaaaaaaaaaaaaaaaa: ${someFunction(
aaaaa + //
bbbb)}`;
llvm-svn: 293636
Summary:
The reflower was not taking into account the additional leading whitespace in block comment lines.
source:
```
{
/*
* long long long long
* long
* long long long long
*/
}
```
format (with column limit 20) before:
```
{
/*
* long long long
* long long long long
* long long
*/
}
```
format after:
```
{
/*
* long long long
* long long long
* long long long
*/
}
```
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: cfe-commits, sammccall, klimek
Differential Revision: https://reviews.llvm.org/D29326
llvm-svn: 293633
Summary:
This fixes a regression that causes example:
```
enum A {
a, // line a
// line b
b
};
```
to be formatted as follows:
```
enum A {
a, // line a
// line b
b
};
```
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: cfe-commits, sammccall, djasper, klimek
Differential Revision: https://reviews.llvm.org/D29322
llvm-svn: 293624
Before:
var f = `aaaaaaaaaaaaa:${aaaaaaa
.aaaaa} aaaaaaaa
aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa`;
After:
var f = `aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa
aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa`;
llvm-svn: 293622
Summary:
This patch stops reflowing comment lines starting with '@', since they commonly
have a special meaning.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29323
llvm-svn: 293617
Summary:
Consider formatting the following code fragment with column limit 20:
```
{
// line 1
// line 2\
// long long long line
}
```
Before this fix the output is:
```
{
// line 1
// line 2\
// long long
long line
}
```
This patch fixes a regression that breaks the last comment line without
adding the '//' prefix.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29298
llvm-svn: 293548
Summary:
The following two comment lines form a single comment section:
```
if (1) { // line 1
// line 2
}
```
This is because the break of a comment section was based on the original column
of the first token of the previous line (in this case, the 'if').
This patch splits these two comment lines into different sections by taking into
account the original column of the right brace preceding the first line comment
where applicable.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29291
llvm-svn: 293539
This had significant negative consequences and I don't have a good
solution for it yet.
Before:
var string =
[
'aaaaaa',
'bbbbbb',
]
.join('+');
After:
var string = [
'aaaaaa',
'bbbbbb',
].join('+');
llvm-svn: 293465
Summary:
The MPEG transport stream file format also uses ".ts" as its file extension.
This change detects its specific framing format (0x47 every 189 bytes) and
simply ignores MPEG TS files.
Reviewers: djasper, sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D29186
llvm-svn: 293270
Summary:
This presents a version of the comment reflowing with less mutable state inside
the comment breakable token subclasses. The state has been pushed into the
driving breakProtrudingToken method. For this, the API of BreakableToken is enriched
by the methods getSplitBefore and getLineLengthAfterSplitBefore.
Reviewers: klimek
Reviewed By: klimek
Subscribers: djasper, klimek, mgorny, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D28764
llvm-svn: 293055
This fixes clang-format not formatting if fallback-style is explicitly set to
"none", and either a config file is found or YAML is passed in without a
"BasedOnStyle". With this change, passing "none" in these cases will have no
affect, and LLVM style will be used as the base style.
Differential Revision: https://reviews.llvm.org/D28844
llvm-svn: 292562
Change the contract of GetStyle so that it returns an error when an error occurs
(i.e. when it writes to stderr), and only returns the fallback style when it
can't find a configuration file.
Differential Revision: https://reviews.llvm.org/D28081
llvm-svn: 292174
Before:
aaaaaaaaaaaaaaaaaa(aaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaaaaaa(aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaa);
No new test cases, as the existing ones cover this fairly well.
llvm-svn: 292110
Summary: Change r291428 introduced ASI detection after closing curly braces. That would generally be correct, however this breaks indentation for structural statements. What happens is that CompoundStatementIndenter increases indentation for the current line, then after reading ASI creates a new line (with the increased line level), and only after the structural parser sees e.g. the if/then/else branch closed, line level is reduced. That leads to the new line started by ASI having a level too high.
Reviewers: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D28763
llvm-svn: 292099
Here, the optimization to not line wrap when it would not lead to a
reduction in columns was overwriting and enforced break that we want to
do no matter what.
Before:
int i = someFunction(
aaaaaaa,
0).aaa(aaaaaaaaaaaaa) *
aaaaaaa +
aaaaaaa;
After:
int i = someFunction(aaaaaaa, 0)
.aaa(aaaaaaaaaaaaa) *
aaaaaaa +
aaaaaaa;
llvm-svn: 291974
Specifically, wrap before them if they are multi-line so that we don't
create long hanging indents. This prevents having a lot of code
indented a lot in some cases.
Before:
someFunction(Param, {List1, List2,
List3});
After:
someFunction(Param,
{List1, List2,
List3});
llvm-svn: 291801
Summary:
Automatic semicolon insertion should break import and export statements:
Before, this would format on one line:
// Note: no semi after 'x' below!
import {x} from 'x'
export function foo() {}
Into:
import {x} from 'x' export function foo() {}
With this change, the statements get separated.
This also improves automatic semicolon insertion to consider closing
braces preceding declarations and statements.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28465
llvm-svn: 291428
Summary:
Before:
declare function foo();
let x = 1;
After:
declare function foo();
let x = 1;
The problem was that clang-format would unconditionally try to parse a child block, even though ambient function declarations do not have a body (similar to forward declarations).
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D28246
llvm-svn: 290959
Modify getStyle to use vfs::FileSystem::makeAbsolute just like FS.addFile does,
rather than sys::fs::make_absolute. The latter gets the CWD from the platform,
while the former expects it to be set by the client, causing a mismatch when
converting relative paths to absolute.
Differential Revision: https://reviews.llvm.org/D27971
llvm-svn: 290319
Members that are themselves wrapped in fake parentheses would lead to
AvoidBinPacking be set on the wrong ParenState.
After:
vector<int> aaaa = {
aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
};
Before we were falling back to bin-packing these.
llvm-svn: 290259
While for <<-operators often used in log statments, a single key value
pair is always on the second operator, e.g.
llvm::errs() << "aaaaa=" << aaaaa;
It is on the first operator for plus- or comma-concatenated strings:
string s = "aaaaaaaaaa: " + aaaaaaaa;
(the "=" not counting because that's a different operator precedence)
llvm-svn: 290177
Before:
SomeLongLoggingStatementOrMacro() << "Some long text "
<< some_variable << "\n";
Before:
SomeLongLoggingStatementOrMacro()
<< "Some long text " << some_variable << "\n";
Short logging statements are already special cased in a different part
of the code.
llvm-svn: 290094
We still want to try in linewrap within single elements of a 1-column
list.
After:
Type *Params[] = {PointerType::getUnqual(FunctionType::get(
Builder.getVoidTy(), Builder.getInt8PtrTy(), false)),
Builder.getInt8PtrTy(),
Builder.getInt32Ty(),
LongType,
LongType,
LongType};
Before:
No line break in the first element, so column limit violation.
llvm-svn: 290090
column limit.
Single-column layout basically means that we format the list with one
element per line. Not doing that when there is a column limit violation
doesn't change the fact that there is an item that doesn't fit within
the column limit.
Before (with a column limit of 30):
std::vector<int> a = {
aaaaaaaa, aaaaaaaa,
aaaaaaaa, aaaaaaaa,
aaaaaaaaaa, aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaa};
After:
std::vector<int> a = {
aaaaaaaa,
aaaaaaaa,
aaaaaaaa,
aaaaaaaa,
aaaaaaaaaa,
aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaa};
(and previously we would have formatted like "After" it wasn't for the one
item that is too long)
llvm-svn: 290084
While C(++) and ObjC are generally formatted the same way and can be
mixed, people might want to choose different styles based on the
language. This patch recognizes .m and .mm files as ObjC and also
implements a very crude detection of whether or not a .h file contains
ObjC code. This can be improved over time.
Also move most of the ObjC tests into their own test file to keep file
size maintainable.
llvm-svn: 289428
Specifically, if the RHS of a comma is a complex binary expression and
spans multiple lines, insert a line break before it. This usually is
often more readable compared to producing a hanging indent. See changes
in FormatTest.cpp for examples.
llvm-svn: 288120
Actual regression was introduced in r272668. This revision fixes JS script, but
also regress Cpp case. It manifests with spaces added when template is followed
with array. Bug 30527 mentions case of array as a nested template type
(foo<bar<baz>[]>). Fix is to detect such case and to prevent treating it as
array initialization, but as a subscript case. However, before r272668, this
case was treated simple because we were detecting it as a StartsObjCMethodExpr.
Same was true for other similar case - array of templates (foo<int>[]). This
patch tries to address two problems: 1) fixing regression 2) making sure both
cases (array as a nested type, array of templates) which were entering
StartsObjCMethodExpr branch are handled now appropriately.
https://reviews.llvm.org/D26163
Patch from Branko Kokanovic <branko@kokanovic.org>!
llvm-svn: 286507
Summary:
During clang-format source lexing >> and << operators are split and
treated as two less/greater operators but column position of following
tokens was not adjusted accordingly.
Fixes PR26887
Patch by Paweł Żukowski.
Reviewers: djasper
Subscribers: malcolm.parsons, mprobst, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D25439
llvm-svn: 285934
Reasoning:
- ExpressionParser uses a lot of stack for these, bad in some environments.
- Our formatting algorithm is N^3 and gets really slow.
- The resulting formatting is unlikely to be any good.
- This is probably generated code we're formatting by accident.
We treat these as unparseable, and signal incomplete formatting. 50 is
an arbitrary number, I've only seen real problems from ~150 levels.
Patch by Sam McCall. Thank you.
llvm-svn: 285570
Summary:
Previously, automatic semicolon insertion would add an unwrapped line
when a template string contained a line break.
var x = `foo${
bar}`;
Would be formatted with `bar...` on a separate line and no indent.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D25675
llvm-svn: 284807
Summary:
Remove colon and commas after replacing constructor body with = default.
Fix annotation of TT_CtorInitializerColon when preceded by a comment.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D25768
llvm-svn: 284732
Summary:
append newline after code when inserting new headers at the end of the
code which does not end with newline.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D21026
llvm-svn: 283330
Fixes the following:
BOOL (^aaa)(void) = ^BOOL {
};
The first BOOL's token was getting set to TT_FunctionAnnotationRParen
incorrectly, which was causing an unexpected newline after (^aaa). This
was introduced in r245846.
Patch by Kent Sutherland, thank you!
llvm-svn: 282448
Summary:
- If a replacement has offset UINT_MAX, length 0, and a replacement text
that is an #include directive, this will insert the #include into the
correct block in the \p Code.
- If a replacement has offset UINT_MAX, length 1, and a replacement text
that is the name of the header to be removed, the header will be removed
from \p Code if it exists.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D24829
llvm-svn: 282253
Summary:
Previously, clang-format would always insert an additional line break after the
import block if the main body started with a comment, due to loosing track of
the first non-import line.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D24708
llvm-svn: 281888
Summary:
`// taze: ... from ...` comments are used help tools where a
specific global symbol comes from.
Before:
// taze: many, different, symbols from
// 'some_long_location_here'
After:
// taze: many, different, symbols from 'some_long_location_here'
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24477
llvm-svn: 281857
Summary:
Before when a semicolon was missing after a boolean literal:
a = true
return 1;
clang-format would parse this as one line and format as:
a = true return 1;
It turns out that C++ does not consider `true` and `false` to be literals, we
have to check for that explicitly.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24574
llvm-svn: 281856
The attempt to fix requoting behavior in r280487 after changes to
tooling::Replacements are incomplete. We essentially need to add to
replacements at the same position, one to insert a line break and one to
change the quoting and that's incompatible with the new
tooling::Replacement API, which does not allow for order-dependent
Replacements. To make the order clear, Replacements::merge() has to be
used, but that requires the merged Replacement to actually refer to the
changed text, which is hard to reproduce for the requoting.
This change fixes the behavior by moving the requoting to a completely
separate pass. The added benefit is that no weird ColumnWidth
calculations are necessary anymore and this should just work even if we
implement string literal splitting in the future.
llvm-svn: 280874
Summary:
When code contains a comment between `return` and the value:
return /* lengthy comment here */ (
lengthyValueComesHere);
Do not wrap before the comment, as that'd break the code through JS' automatic
semicolon insertion.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24257
llvm-svn: 280730
Summary:
When formatting source code that needs both requoting and reindentation,
merge the replacements to avoid erroring out for conflicting replacements.
Also removes the misleading Replacements parameter from the
TokenAnalyzer API.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24155
llvm-svn: 280487
Summary:
Default imports appear outside of named bindings in curly braces:
import A from 'a';
import A, {symbol} from 'a';
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D23973
llvm-svn: 280486
Summary:
User feedback is that they expect *all* imports to be sorted if any import was
affected by a change, not just imports up to the first non-affected line, as
clang-format currently does.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D23972
llvm-svn: 280485
JavaScript template strings can be nested arbitrarily:
foo = `text ${es.map(e => { return `<${e}>`; })} text`;
This change lexes nested template strings using a stack of lexer states to
correctly switch back to template string lexing on closing braces.
Also, reuse the same stack for the token-stashed logic.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D22431
llvm-svn: 279727
Manuel Klimek