A template specialization of a template foo<int N> can contain integer constants and a whole bunch of operators - e. g. foo< 1 ? !0 : (3+1)%4 >
Inspired by https://reviews.llvm.org/D58922
Differential Revision: https://reviews.llvm.org/D58934
llvm-svn: 355434
Summary:
If the clang-format on/off is in a /* comment */ then the sorting of headers is not ignored
PR40901 - https://bugs.llvm.org/show_bug.cgi?id=40901
Reviewers: djasper, klimek, JonasToth, krasimir, alexfh
Reviewed By: alexfh
Subscribers: alexfh, cfe-commits, llvm-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58819
llvm-svn: 355266
Summary:
clang-formatting wants to add spaces around items in square braces, e.g. [1, 2] -> [ 1, 2 ]. Based on a quick check [1], it seems like most cases are using the [1, 2] format, so make that the consistent one.
[1] in llvm `.td` files, the regex `\[[^ ]` (bracket followed by not-a-space) shows up ~400 times, but `\[\s[^ ]` (bracket followed by one space and one not-a-space) shows up ~40 times => ~90% uses this format.
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D55964
llvm-svn: 355158
Summary:
getLLVMStyle() sets the default style, but doesn't take the language as a parameter, so can't set default parameters when they differ from C++. This change adds LanguageKind as an input to getLLVMStyle so that we can start doing that.
See D55964 as a motivation for this, where we want Tablegen to be formatted differently than C++.
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: jdoerfert, MyDeveloperDay, kristina, cfe-commits, arphaman
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56943
llvm-svn: 355123
Summary:
Currently clang-format would always emit a replacement for a block of Java imports even if it is correctly formatted:
```
% cat /tmp/Aggregator.java
import X;
% clang-format /tmp/Aggregator.java
import X;
% clang-format -output-replacements-xml /tmp/Aggregator.java
<?xml version='1.0'?>
<replacements xml:space='preserve' incomplete_format='false'>
<replacement offset='0' length='9'>import X;</replacement>
</replacements>
%
```
This change makes clang-format not emit replacements in this case. Note that
there is logic to not emit replacements in this case for C++.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58436
llvm-svn: 354452
Trailing comments are not always aligned properly when UseTab is set to Always.
Consider:
int a; // x
int bbbbbbbb; // x
With .clang-format:
---
Language: Cpp
BasedOnStyle: LLVM
UseTab: Always
...
The trailing comments of this code block should be aligned, but aren't
To align the first trailing comment it needs to insert 8 spaces. This should be
one tab plus six spaces. It skips the logic of the first partial tab in
FirstTabWidth (=2) + Style.TabWidth (=8) <= Spaces (=8) and only inserts one
tab. Proposed fix and test is attached.
Patch by Hylke Kleve.
Differential revision: https://reviews.llvm.org/D57655
llvm-svn: 354183
Summary:
Currently, `UnwrappedLineParser` thinks an arrow token after
an ObjC method expression is a C++ lambda arrow, so it formats:
```
[foo bar]->baz
```
as:
```
[foo bar] -> baz
```
Because `UnwrappedLineParser` runs before `TokenAnnotator`, it can't
know if the arrow token is after an ObjC method expression or not.
This diff makes `TokenAnnotator` remove the TT_LambdaArrow on
the arrow token if it follows an ObjC method expression.
Test Plan: New test added. Ran test with:
% ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
Confirmed test failed before diff and passed after diff.
Reviewers: krasimir, djasper, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57923
llvm-svn: 353531
Summary:
From https://bugs.llvm.org/show_bug.cgi?id=40516
```
$ cat a.cpp
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::myFunction() {
// do stuff
}
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::operator++() {
// do stuff
}
$ ~/ll/build/opt/bin/clang-format -style=LLVM a.cpp
const NamespaceName::VeryLongClassName &
NamespaceName::VeryLongClassName::myFunction() {
// do stuff
}
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::
operator++() {
// do stuff
}
```
What was happening is that the split penalty before `operator` was being set to
a smaller value by a prior if block. Moved checks around to fix this and added a
regression test.
Reviewers: djasper
Reviewed By: djasper
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57604
llvm-svn: 353033
The commit r322690 introduced support for ObjC detection in header files.
Unfortunately some C headers that use designated initializers are now
incorrectly detected as Objective-C.
This commit fixes it by ensuring that `[ token ]` is not annotated as an
Objective-C message send.
rdar://45504376
Differential Revision: https://reviews.llvm.org/D56226
llvm-svn: 352125
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
It's a new primitive for importing symbols, and should be treated like
the (previously handled) `goog.require` and `goog.forwardDeclare`.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56385
llvm-svn: 350516
Summary:
r346756 refined clang-format to not treat the `[` in `asm (...: [] ..)` as an
ObjCExpr. However that's not enough, as we might have a comma-separated list of
such clobbers as in the newly added test.
This updates the detection to instead look at the Line's first token being `asm`
and not mark `[`-s as ObjCExprs in this case.
Reviewers: djasper, benhamilton
Reviewed By: djasper, benhamilton
Subscribers: benhamilton, cfe-commits
Differential Revision: https://reviews.llvm.org/D54795
llvm-svn: 347465
Summary:
Clang-format is treating all occurences of `is` in js as type matchers. In some
cases this is wrong, as it might be a dict key.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54753
llvm-svn: 347307
Summary:
The opening square of an inline asm clobber was being annotated as an ObjCExpr.
This caused, amongst other things, the ObjCGuesser to guess header files
containing that pattern as ObjC files.
Reviewers: benhamilton
Reviewed By: benhamilton
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54111
llvm-svn: 346756
Summary:
clang-format can get confused by string literals in TableGen: it knows that strings can be broken up, but doesn't seem to understand how that can be indented across line breaks, and arranges them in a weird triangular pattern. Take this output example from `clang-format tools/llvm-objcopy/ObjcopyOpts.td` (which has now been formatted in rL345896 with this patch applied):
```
defm keep_global_symbols
: Eq<
"keep-global-symbols", "Reads a list of symbols from <filename> and "
"runs as if " "--keep-global-symbol=<symbol> "
"is set for each one. "
"<filename> " "contains one "
"symbol per line "
"and may contain "
"comments "
"beginning " "with"
" '#'"
". "
"Lead"
"ing "
```
Reviewers: alexshap, MaskRay, djasper
Reviewed By: MaskRay
Subscribers: krasimir, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D53952
llvm-svn: 346687
Summary:
The issue is that for array subscript like:
```
arr[[Foo() bar]];
```
ClangFormat will recognize it as C++11 attribute syntax and put a space between 'arr' and first '[', like:
```
arr [[Foo() bar]];
```
Now it is fixed. Tested with:
```
ninja FormatTests
```
Reviewers: benhamilton
Reviewed By: benhamilton
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54288
llvm-svn: 346566
Summary:
This is done in order to improve cases where the lambda's body is moved too far to the right. Consider the following snippet with column limit set to 79:
```
void f() {
leader::MakeThisCallHere(&leader_service_,
cq_.get(),
[this, liveness](const leader::ReadRecordReq& req,
std::function<void()> done) {
logger_->HandleReadRecord(
req, resp, std::move(done));
});
leader::MakeAnother(&leader_service_,
cq_.get(),
[this, liveness](const leader::ReadRecordReq& req,
std::function<void()> done) {
logger_->HandleReadRecord(
req, resp, std::move(done), a);
});
}
```
The tool favors extra indentation for the lambda body and so the code incurs extra wrapping and adjacent calls are indented to a different level. I find this behavior annoying and I'd like the tool to favor new lines and, thus, use the extra width.
The fix, reduced, brings the following formatting.
Before:
function(1,
[] {
DoStuff();
//
},
1);
After:
function(
1,
[] {
DoStuff();
//
},
1);
Refer to the new tests in FormatTest.cpp
Contributed by oleg.smolsky!
Reviewers: djasper, klimek, krasimir
Subscribers: cfe-commits, owenpan
Tags: #clang
Differential Revision: https://reviews.llvm.org/D52676
llvm-svn: 345753
Summary:
Currently clang-format breaks before the next parameter after multiline parameters (also recursively for the parent expressions of multiline parameters). However, it fails to do so for formatted multiline raw string literals:
```
$ cat test.cc
// Examples
// Regular multiline tokens
int x = f(R"(multi
line)", 2);
}
int y = g(h(R"(multi
line)"), 2);
// Formatted multiline tokens
int z = f(R"pb(multi: 1 #
line: 2)pb", 2);
int w = g(h(R"pb(multi: 1 #
line: 2)pb"), 2);
$ clang-format -style=google test.cc
// Examples
// Regular multiline tokens
int x = f(R"(multi
line)",
2);
}
int y = g(h(R"(multi
line)"),
2);
// Formatted multiline tokens
int z = f(R"pb(multi: 1 #
line: 2)pb", 2);
int w = g(h(R"pb(multi: 1 #
line: 2)pb"), 2);
```
This patch addresses this inconsistency by forcing breaking after multiline formatted raw string literals. This requires a little tweak to the indentation chosen for the contents of a formatted raw string literal: in case when that's a parameter and not the last one, the indentation is based off of the uniform indentation of all of the parameters.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52448
llvm-svn: 345242
Previously, Java annotation declarations (@interface AnnotationName) were being
handled as ObjC interfaces. This caused the brace formatting to mess up, so
that when you had a class with an interface defined in it, it would indent the
final brace of the class.
It used to format this class like so:
class A {
@interface B {}
}
But will now just skip the @interface and format it like so:
class A {
@interface B {}
}
Patch by Sam Maier!
Differential Revision: https://reviews.llvm.org/D53434
llvm-svn: 344789
This patch moves the virtual file system form clang to llvm so it can be
used by more projects.
Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
- Moves the corresponding unit test from clang to llvm.
- Moves the vfs namespace from clang::vfs to llvm::vfs.
- Formats the lines affected by this change, mostly this is the result of
the added llvm namespace.
RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html
Differential revision: https://reviews.llvm.org/D52783
llvm-svn: 344140
The existing code kept the space if it was there for identifiers, and it didn't
handle `this`. After this patch, for Java `this` is handled in addition to
identifiers, and existing space is always stripped between identifier and `::`.
Also accept `::` in addition to `.` in front of `<` in `foo::<T>bar` generic
calls.
Differential Revision: https://reviews.llvm.org/D52842
llvm-svn: 343872
Summary:
Some macros are used in the body of function, and actually contain the trailing semicolon: they should thus be automatically followed by a new line, and not get merged with the next line. This is for example the case with Qt's Q_UNUSED macro:
void foo(int a, int b) {
Q_UNUSED(a)
return b;
}
This patch deals with these cases by introducing a new option to specify list of statement macros. This re-uses the system already in place for foreach macros, to ensure there is no impact on performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: krasimir
Subscribers: acoomans, mgrang, alexfh, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33440
llvm-svn: 343602
Summary:
This change adds some rudimentary support for conditional types.
Specifically it avoids breaking before `extends` and `infer` keywords,
which are subject to Automatic Semicolon Insertion, so breaking before
them creates incorrect syntax.
The actual formatting of the type expression is odd, but there is as of
yet no clear idea on how to format these.
See https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#conditional-types.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52536
llvm-svn: 343179
This fixes formatting namespaces with preceding 'inline' and 'export' (Modules TS) specifiers.
This change fixes namespaces not being identified as such with preceding 'inline' or 'export' specifiers.
Motivation: I was experimenting with the Modules TS (-fmodules-ts) and found it would be useful if clang-format would correctly format 'export namespace'. While making the changes, I noticed that similar issues still exist with 'inline namespace', and addressed them as well.
Patch by Marco Elver!
Reviewers: klimek, djasper, owenpan, sammccall
Reviewed By: owenpan, sammccall
Subscribers: owenpan, cfe-commits
Differential Revision: https://reviews.llvm.org/D51036
llvm-svn: 341450
Summary:
The Bug was reported and fixed by Owen Pan. See the original bug report here: https://bugs.llvm.org/show_bug.cgi?id=38557
Patch by Owen Pan!
Reviewers: krasimir, djasper, klimek
Reviewed By: klimek
Subscribers: JonasToth, cfe-commits
Differential Revision: https://reviews.llvm.org/D50697
llvm-svn: 340624
Summary:
This fixes a bug in clang-format where the last line's penalty is not
taken into account when its ending is broken. Usually the last line's penalty
is handled by addNextStateToQueue, but in cases where the trailing `*/` is put
on a newline, the contents of the last line have to be considered for penalizing.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50378
llvm-svn: 339123
Summary:
Previously, clang-format would avoid breaking before the first `{`
found, but then happily break before subsequent '{'s on the line. This
change fixes that by looking for the first location that has no opening
curly, if any.
This fixes the original commit by correcting the loop condition.
This reverts commit 66dc646e09b795b943668179c33d09da71a3b6bc.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50249
llvm-svn: 338890
Summary:
Previously, clang-format would avoid breaking before the first `{`
found, but then happily break before subsequent '{'s on the line. This
change fixes that by looking for the first location that has no opening
curly, if any.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50230
llvm-svn: 338837
Summary:
Previously, clang-format would crash if it tried to wrap an overlong
single line comment, because two parts of the code inserted a break in
the same location.
/** heregoesalongcommentwithnospace */
This wasn't previously noticed as it could only trigger for an overlong
single line comment that did have no breaking opportunities except for a
whitespace at the very beginning.
This also introduces a check for JavaScript to not ever wrap a comment
before an opening curly brace:
/** @mods {donotbreakbeforethecurly} */
This is because some machinery parsing these tags sometimes supports
breaks before a possible `{`, but in some other cases does not.
Previously clang-format was careful never to wrap a line with certain
tags on it. The better solution is to specifically disable wrapping
before the problematic token: this allows wrapping and aligning comments
but still avoids the problem.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50177
llvm-svn: 338706
Summary:
Bug was caused due to comments at the start of scope. For a code like:
```
int func() { //
int b;
int c;
}
```
the comment at the first line gets IndentAndNestingLevel (1,1) whereas
the following declarations get only (0,1) which prevents them from insertion
of a new scope. So, I changed the AlignTokenSequence to look at previous
*non-comment* token when deciding whether to introduce a new scope into
stack or not.
Patch by Kadir Cetinkaya!
Reviewers: rsmith, djasper
Reviewed By: djasper
Subscribers: lebedev.ri, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D43303
llvm-svn: 338578
Summary:
This patch makes clang-format indent the subsequent lines created by breaking a
long javadoc annotated line.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: acoomans, cfe-commits
Differential Revision: https://reviews.llvm.org/D49797
llvm-svn: 338232
Reapply D47195:
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.
llvm-svn: 336521
Reduce penalty for aligning ObjC method arguments using the colon alignment as
this is the canonical way.
Trying to fit a whole expression into one line should not force other line
breaks (e.g. when ObjC method expression is a part of other expression).
llvm-svn: 336520
Summary:
In D44638, I partially fixed `NS_SWIFT_NAME(foo(bar:baz:))`-style
annotations on C functions, but didn't add a test for Objective-C
method declarations.
For ObjC method declarations which are annotated with `NS_SWIFT_NAME(...)`,
we currently fail to annotate the final component of the selector
name as `TT_SelectorName`.
Because the token type is left unknown, clang-format will happily
cause a compilation error when it changes the following:
```
@interface Foo
- (void)doStuffWithFoo:(id)name
bar:(id)bar
baz:(id)baz
NS_SWIFT_NAME(doStuff(withFoo:bar:baz:));
@end
```
to:
```
@interface Foo
- (void)doStuffWithFoo:(id)name
bar:(id)bar
baz:(id)baz
NS_SWIFT_NAME(doStuff(withFoo:bar:baz
:));
@end
```
(note the linebreak before the final `:`).
The logic which decides whether or not to annotate the token before a
`:` with `TT_SelectorName` is pretty fragile, and has to handle some
pretty odd cases like pair-parameters:
```
[I drawRectOn:surface ofSize:aa:bbb atOrigin:cc:dd];
```
So, to minimize the effect of this change, I decided to only annotate
unknown identifiers before a `:` as `TT_SelectorName` for Objective-C
declaration lines.
Test Plan: New tests included. Confirmed tests failed before change and
passed after change. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, krasimir, jolesiak
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48679
llvm-svn: 335983
Summary:
This stops clang-format from touching raw string contents with unrecognized delimiters inside recognized functions.
Unrecognized delimiters signal that the string might be special.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48728
llvm-svn: 335876
Summary:
In C++ code snippets of the form `@field` are common. This makes clang-format
keep them together in text protos, whereas before it would break them.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48543
llvm-svn: 335459
Summary:
The case of end-of-file comments was formatted badly:
```
key: value
# end-of-file comment
```
This patch fixes that formatting:
```
key: value
# end-of-file comment
```
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48539
llvm-svn: 335449
WebKit C++ style for object initialization is as follows:
Foo foo { bar };
Yet using clang-format -style=webkit changes this to:
Foo foo{ bar };
As there is no existing combination of rules that will ensure a space
before a braced list in this fashion, this patch adds a new
SpaceBeforeCpp11BracedList rule.
Patch by Ross Kirsling!
Differential Revision: https://reviews.llvm.org/D46024
llvm-svn: 334692
Summary:
The added test case was currently crashing with an assertion:
```
krasimir@krasimir> cat test.cc ~
// How to run:
// bbbbb run \
// rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr \
// <log_file> -- --output_directory="<output_directory>"
krasimir@krasimir> ~/work/llvm-build/bin/clang-format test.cc ~
clang-format: /usr/local/google/home/krasimir/work/llvm/tools/clang/lib/Format/WhitespaceManager.cpp:117: void clang::format::WhitespaceManager::calculateLineBreakInformation(): Assertion `PreviousOriginalWhitespaceEndOffset <= OriginalWhitespaceStartOffset' failed.
```
The root cause was that BreakableToken was not considering the case of a reflow between an unescaped newline in a line comment.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48089
llvm-svn: 334527
Summary:
Currently clang-format allows this for text protos:
```
submessage:
{ key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' }
```
when it is under the column limit and when putting it all on one line exceeds the column limit.
This is not a very intuitive formatting, so I'd prefer having
```
submessage: {
key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
}
```
instead, even if it takes one line more.
This patch prevents clang-format from inserting a break between `: {` and similar cases.
Reviewers: djasper, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48063
llvm-svn: 334517
Summary:
TypeScript uses the `!` token for strict property initialization
assertions, as in:
class X {
strictPropAsserted!: string;
}
Previously, clang-format would wrap between the `!` and the `:` for
overly long lines. This patch fixes that by generally preventing the
wrap in that location.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48030
llvm-svn: 334415
Summary:
This option replaces the BreakBeforeInheritanceComma option with an
enum, thus introducing a mode where the colon stays on the same line as
constructor declaration:
// When it fits on line:
class A : public B, public C {
...
};
// When it does not fit:
class A :
public B,
public C {
...
};
This matches the behavior of the `BreakConstructorInitializers` option,
introduced in https://reviews.llvm.org/D32479.
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: mzeren-vmw, cfe-commits
Differential Revision: https://reviews.llvm.org/D43015
llvm-svn: 334408
Summary:
This patch updates clang-format text protos to put entries of a submessage into separate lines if the submessage contains at least two entries and contains at least one submessage entry.
For example, the entries here are kept on separate lines even if putting them on a single line would be under the column limit:
```
message: {
entry: 1
submessage: { key: value }
}
```
Messages containing a single submessage or several scalar entries can still be put on one line if they fit:
```
message { submessage { key: value } }
message { x: 1 y: 2 z: 3 }
```
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46757
llvm-svn: 334401
Summary: We were missing the case when python-style comments in text protos start with `##`.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D47870
llvm-svn: 334179
Summary:
Please take a close look at this CL. I haven't touched much of
`UnwrappedLineParser` before, so I may have gotten things wrong.
Previously, clang-format would incorrectly format the following:
```
@implementation Foo
- (Class)class {
}
- (void)foo {
}
@end
```
as:
```
@implementation Foo
- (Class)class {
}
- (void)foo {
}
@end
```
The problem is whenever `UnwrappedLineParser::parseStructuralElement()`
sees any of the keywords `class`, `struct`, or `enum`, it calls
`parseRecord()` to parse them as a C/C++ record.
This causes subsequent lines to be parsed incorrectly, which
causes them to be indented incorrectly.
In Objective-C/Objective-C++, these keywords are valid selector
components.
This diff fixes the issue by explicitly handling `+` and `-` lines
inside `@implementation` / `@interface` / `@protocol` blocks
and parsing them as Objective-C methods.
Test Plan: New tests added. Ran tests with:
make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: jolesiak, klimek
Reviewed By: jolesiak, klimek
Subscribers: klimek, cfe-commits, Wizard
Differential Revision: https://reviews.llvm.org/D47095
llvm-svn: 333553
Summary:
Reapply reverted changes from D46879.
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.
Test Plan:
make -j12 FormatTests && tools/clang/unittests/Format/FormatTests
Reviewers: benhamilton, krasimir
Reviewed By: benhamilton, krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D47195
llvm-svn: 333171
Summary:
This patch fixes two bugs in clang-format where the template wrapper doesn't skip over
comments causing a long template declaration to not be split into multiple lines.
These were latent and exposed by r332436.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D47257
llvm-svn: 333085
Summary:
`is` type annotations can occur at any nesting level. For example:
function x() {
return function y(): a is B { ... };
}
Breaking before the `is` above breaks TypeScript parsing the code. This
change prevents the wrap.
Reviewers: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D47193
llvm-svn: 332968
Summary:
Previously, clang-format's parser would fail to annotate the
selector in a single-component Objective-C method invocation with
`TT_SelectorName`. For example, the following:
[foo bar];
would parse `bar` as `TT_Unknown`:
M=0 C=1 T=Unknown S=0 B=0 BK=0 P=140 Name=identifier L=34 PPK=2
FakeLParens= FakeRParens=0 II=0x559d5db51770 Text='bar'
This caused us to fail to insert a space after a closing cast rparen,
so the following:
[((Foo *)foo) bar];
would format as:
[((Foo *)foo)bar];
This diff fixes the issue by ensuring we annotate the selector
in a single-component Objective-C method invocation as
`TT_SelectorName`.
Test Plan: New tests added. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak
Reviewed By: jolesiak
Subscribers: Wizard, klimek, hokein, cfe-commits
Differential Revision: https://reviews.llvm.org/D47028
llvm-svn: 332727
Summary:
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.
Test Plan:
make -j12 FormatTests && tools/clang/unittests/Format/FormatTests
Reviewers: benhamilton, djasper
Reviewed By: benhamilton
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46879
llvm-svn: 332582
Summary:
Introduce `PenaltyBreakTemplateDeclaration` to control the penalty,
and change `AlwaysBreakTemplateDeclarations` to an enum with 3 modes:
* `No` for regular, penalty based, wrapping of template declaration
* `MultiLine` for always wrapping before multi-line declarations (e.g.
same as legacy behavior when `AlwaysBreakTemplateDeclarations=false`)
* `Yes` for always wrapping (e.g. same as legacy behavior when
`AlwaysBreakTemplateDeclarations=true`)
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42684
llvm-svn: 332436
Summary:
This patch changes the behavior of PenaltyBreakBeforeFirstCallParameter
so that is does not apply after a brace, when Cpp11BracedListStyle is
false.
This way, variable initialization is wrapped more like an initializer
than like a function call, which is more consistent with user
expectations for this braced list style.
With PenaltyBreakBeforeFirstCallParameter=200, this gives the following
code: (with Cpp11BracedListStyle=false)
Before :
const std::unordered_map<std::string, int> Something::MyHashTable =
{ { "aaaaaaaaaaaaaaaaaaaaa", 0 },
{ "bbbbbbbbbbbbbbbbbbbbb", 1 },
{ "ccccccccccccccccccccc", 2 } };
After :
const std::unordered_set<std::string> Something::MyUnorderedSet = {
{ "aaaaaaaaaaaaaaaaaaaaa", 0 },
{ "bbbbbbbbbbbbbbbbbbbbb", 1 },
{ "ccccccccccccccccccccc", 2 }
};
Reviewers: krasimir, djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43290
llvm-svn: 332434
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Explicitly avoided changing the strings in the clang-format tests.
Differential Revision: https://reviews.llvm.org/D44975
llvm-svn: 332350
Summary: This will be shared by include insertion/deletion library.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: mgorny, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46758
llvm-svn: 332284
Summary:
This fixes a regression introduced by `r331857` where we stop the search for
the End token as soon as we hit a non-scope-closer, which prematurely stops before
semicolons for example, which should otherwise be considered as part of the unbreakable tail.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46824
llvm-svn: 332225
Summary:
This patch makes `getLengthToMatchingParen` respect the `BreakBeforeClosingBrace`
ParenState for matching scope closers. In order to distinguish between paren states
introduced by real vs. fake parens, I've added the token opening the ParensState
to that struct.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46519
llvm-svn: 331857
Summary:
The class will be moved into libToolingCore as followup.
The new behaviors in this patch:
- New #include is inserted in the right position in a #include block to
preserver sorted #includes. This is best effort - only works when the
block is already sorted.
- When inserting multiple #includes to the end of a file which doesn't
end with a "\n" character, a "\n" will be prepended to each #include.
This is a special and rare case that was previously handled. This is now
relaxed to avoid complexity as it's rare in practice.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: klimek, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D46180
llvm-svn: 331544
Summary:
Previously, we checked tokens for `tok::identifier` to see if they
were identifiers inside an Objective-C selector.
However, this missed C++ keywords like `new` and `delete`.
To fix this, this diff uses `getIdentifierInfo()` to find
identifiers or keywords inside Objective-C selectors.
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/D46143
llvm-svn: 331067
This required a couple of yaks to be shaved:
1. MatchingOpeningBlockLineIndex was misused to also store the
closing index; instead, use a second variable, as this doesn't
work correctly for "} else {".
2. We needed to change the API of AffectedRangeManager to not
use iterators; we always passed in begin / end for the whole
container before, so there was no mismatch in generality.
3. We need an extra check to discontinue formatting at the top
level, as we now sometimes change the indent of the closing
brace, but want to bail out immediately afterwards, for
example:
void f() {
if (a) {
}
void g();
Previously:
void f() {
if (a) {
}
void g();
Now:
void f() {
if (a) {
}
void g();
Differential Revision: https://reviews.llvm.org/D45726
llvm-svn: 330573
This reverts commit r330016.
The incomplete detection has too many false positives, picking up typos
for hard failures and refusing to format anything in that case.
llvm-svn: 330569
Summary:
This patch improves detection of incomplete code for protos and text protos.
This is especially important for text protos in raw string literals, since they
might be partial strings concatenated, and we'd like to disable formatting in
these cases.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44203
llvm-svn: 330016
Summary:
Previously, `clang-format` would break Objective-C
category extensions after the opening parenthesis to avoid
breaking the protocol list:
```
% echo "@interface ccccccccccccc (ccccccccccc) <ccccccccccccc> { }" | \
clang-format -assume-filename=foo.h -style="{BasedOnStyle: llvm, \
ColumnLimit: 40}"
@interface ccccccccccccc (
ccccccccccc) <ccccccccccccc> {
}
```
This looks fairly odd, as we could have kept the category extension
on the previous line.
Category extensions are a single item, so they are generally very
short compared to protocol lists. We should prefer breaking after the
opening `<` of the protocol list over breaking after the opening `(`
of the category extension.
With this diff, we now avoid breaking after the category extension's
open paren, which causes us to break after the protocol list's
open angle bracket:
```
% echo "@interface ccccccccccccc (ccccccccccc) <ccccccccccccc> { }" | \
./bin/clang-format -assume-filename=foo.h -style="{BasedOnStyle: llvm, \
ColumnLimit: 40}"
@interface ccccccccccccc (ccccccccccc) <
ccccccccccccc> {
}
```
Test Plan: New test added. Confirmed test failed before diff and
passed after diff by running:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45526
llvm-svn: 329919
Summary:
This diff improves the Objective-C guessing heuristic by
replacing the hard-coded list of a subset of Objective-C @keywords
with a general check which supports all @keywords.
I also added a few more Foundation keywords which were missing from
the heuristic.
Test Plan: Unit tests updated. 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/D45521
llvm-svn: 329918
Summary:
In D45185, I added clang-format parser support for Objective-C
generics. However, I didn't touch the whitespace logic, so they
got the same space logic as Objective-C protocol lists.
In every example in the Apple SDK and in the documentation,
there is no space between the class name and the opening `<`
for the lightweight generic specification, so this diff
removes the space and updates the tests.
Test Plan: Tests updated. 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/D45498
llvm-svn: 329917
Summary:
Currently, indentation of Objective-C method names which are wrapped
onto the next line due to a long return type is controlled by the
style option `IndentWrappedFunctionNames`.
This diff changes the behavior so we always indent wrapped Objective-C
selector names.
NOTE: I partially reverted 6159c0fbd1 / rL242484, as it was causing wrapped selectors to be double-indented. Its tests in FormatTestObjC.cpp still pass.
Test Plan: Tests updated. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, jolesiak, stephanemoore, thakis
Reviewed By: djasper
Subscribers: stephanemoore, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D45004
llvm-svn: 329916
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
Jan Korous