Summary:
Other macros are used to declare namespaces, and should thus be handled
similarly. This is the case for crpcut's TESTSUITE macro, or for
unittest-cpp's SUITE macro:
TESTSUITE(Foo) {
TEST(MyFirstTest) {
assert(0);
}
} // TESTSUITE(Foo)
This patch deals with this cases by introducing a new option to specify
lists of namespace macros. Internally, it re-uses the system already in
place for foreach and statement macros, to ensure there is no impact on
performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: klimek
Subscribers: acoomans, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37813
llvm-svn: 362740
Summary:
Adds a `TypenameMacros` configuration option that causes certain identifiers to be handled in a way similar to `typeof()`.
This is enough to:
- Prevent misinterpreting declarations of pointers to such types as expressions (`STACK_OF(int) * foo` -> `STACK_OF(int) *foo`),
- Avoid surprising line breaks in variable/struct field declarations (`STACK_OF(int)\nfoo;` -> `STACK_OF(int) foo;`, see https://bugs.llvm.org/show_bug.cgi?id=30353).
Reviewers: Typz, krasimir, djasper
Reviewed By: Typz
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57184
llvm-svn: 361986
Summary:
Top-level "package" and "import" statements should generally be kept on
one line, for all languages.
----
This reverts commit rL356912.
The regression from rL356835 was fixed via rC358275.
Reviewers: krasimir, sammccall, MyDeveloperDay, xinz, dchai, klimek
Reviewed By: krasimir, xinz, dchai
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60661
llvm-svn: 360411
Summary:
AnnotatingParser::next() is needed to implicitly set TT_BlockComment
versus TT_LineComment. On most other paths through
AnnotatingParser::parseLine(), all tokens are consumed to achieve that.
This change updates one place where this wasn't done.
Contributed by @dchai!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60541
llvm-svn: 358275
Summary:
Addresses PR40696 - https://bugs.llvm.org/show_bug.cgi?id=40696
The BreakAfterReturnType didn't work if it had a single arguments which was a template with an integer template parameter
```
int foo(A<8> a) { return a; }
```
When run with the Mozilla style. would not break after the `int`
```
int TestFn(A<8> a)
{
return a;
}
```
This revision resolves this issue by allowing numeric constants to be considered function parameters if if seen inside `<>`
Reviewers: djasper, klimek, JonasToth, krasimir, reuk, alexfh
Reviewed By: klimek
Subscribers: cfe-commits, llvm-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59309
llvm-svn: 357837
This patch aims to add support for the following rules from the JUCE coding standards:
- Always put a space before an open parenthesis that contains text - e.g. foo (123);
- Never put a space before an empty pair of open/close parenthesis - e.g. foo();
Patch by Reuben Thomas
Differential Revision: https://reviews.llvm.org/D55170
llvm-svn: 357344
Summary:
This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas.
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57687
llvm-svn: 357027
Summary:
Revision r356575 had the unfortunate consequence that now clang-format never
detects an ObjC call expression after `&&`.
This patch tries harder to distinguish between C++17 structured bindings and
ObjC call expressions and adds a few regression tests.
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59774
llvm-svn: 356928
This reverts commit r356835. This patch causes a regression, see the
test below:
verifyFormat("// Detached comment\n\n"
"// Leading comment\n"
"syntax = \"proto2\"; // trailing comment\n\n"
"// in foo.bar package\n"
"package foo.bar; // foo.bar package\n");
llvm-svn: 356912
Summary:
Top-level "package" and "import" statements should generally be kept on one
line, for all languages.
Reviewers: sammccall, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59627
Patch By: dchai (Donald Chai)
llvm-svn: 356835
Summary:
This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.
Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850
Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.
I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..)
Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile.
Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.
Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted.
Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth
Reviewed By: klimek
Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58404
llvm-svn: 356662
Summary:
Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++
Reported by: https://twitter.com/mattgodbolt/status/1096188576503644160
$ clang-format.exe test.h
Configuration file(s) do(es) not support Objective-C: C:\clang\build\.clang-format
--- test.h --
```
std::vector<std::pair<std::string,std::string>> C;
void foo()
{
for (auto && [A,B] : C)
{
std::string D = A + B;
}
}
```
The following code fixes this issue of incorrect detection
Reviewers: djasper, klimek, JonasToth, reuk
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59546
llvm-svn: 356575
Before:
const x = veryLongIdentifier
`hello`;
After:
const x =
veryLongIdentifier`hello`;
While it's allowed to have the template string and tag identifier
separated by a line break, currently the clang-format output is not
stable when a break is forced. Additionally, disallowing a line break
makes it clear that the identifier is actually a tag for a template
string.
Patch originally by mitchellwills (thanks!).
llvm-svn: 356447
Previously revisions commited non-clang-formatted changes to the Format library, this means submitting any revision e.g. {D55170} can cause additional whitespace changes to potentially be included in a revision.
Commit a non functional change using latest build Windows clang-format r351376 with no other changes, to remove these differences
All FormatTests
pass [==========] 652 tests from 20 test cases ran.
llvm-svn: 355182
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
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:
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
Reduce penalty for aligning ObjC method arguments using the colon alignment as
this is the canonical way.
Trying to fit a whole expression into one line should not force other line
breaks (e.g. when ObjC method expression is a part of other expression).
llvm-svn: 336520
Summary:
Counts selector parts also for method declarations and counts correctly for methods without arguments.
This is an internal change and doesn't influence formatting on its own (at the current state). Its lack would be visible after applying D48719.
Reviewers: benhamilton, klimek
Reviewed By: benhamilton
Subscribers: acoomans, cfe-commits
Differential Revision: https://reviews.llvm.org/D48716
llvm-svn: 336518
Summary:
In D44638, I partially fixed `NS_SWIFT_NAME(foo(bar:baz:))`-style
annotations on C functions, but didn't add a test for Objective-C
method declarations.
For ObjC method declarations which are annotated with `NS_SWIFT_NAME(...)`,
we currently fail to annotate the final component of the selector
name as `TT_SelectorName`.
Because the token type is left unknown, clang-format will happily
cause a compilation error when it changes the following:
```
@interface Foo
- (void)doStuffWithFoo:(id)name
bar:(id)bar
baz:(id)baz
NS_SWIFT_NAME(doStuff(withFoo:bar:baz:));
@end
```
to:
```
@interface Foo
- (void)doStuffWithFoo:(id)name
bar:(id)bar
baz:(id)baz
NS_SWIFT_NAME(doStuff(withFoo:bar:baz
:));
@end
```
(note the linebreak before the final `:`).
The logic which decides whether or not to annotate the token before a
`:` with `TT_SelectorName` is pretty fragile, and has to handle some
pretty odd cases like pair-parameters:
```
[I drawRectOn:surface ofSize:aa:bbb atOrigin:cc:dd];
```
So, to minimize the effect of this change, I decided to only annotate
unknown identifiers before a `:` as `TT_SelectorName` for Objective-C
declaration lines.
Test Plan: New tests included. Confirmed tests failed before change and
passed after change. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests
Reviewers: djasper, krasimir, jolesiak
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48679
llvm-svn: 335983
Summary:
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
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:
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:
`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:
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
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
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 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
Francois Ferrand