This changes the behavior of AlwaysBreakAfterDeclarationReturnType
so that it supports breaking after declarations, definitions, or
both.
Differential Revision: http://reviews.llvm.org/D10370
Reviewed By: Daniel Jasper
llvm-svn: 256046
Revision 251405 added AlwaysBreak to support Google's JavaScript style. This
changeset complete existing AlignsAfterOpenBracket tests to exercise
AlwaysBreak for C++.
I thought this would be worthwhile. With this option we can support request
from http://lists.llvm.org/pipermail/cfe-dev/2015-May/042942.html, that had
been requested a few times. This also partially solve related Bug 23422 and is
probably sufficient for most people.
AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
BinPackArguments = false;
BinPackParameters = false;
With these setting we obtain this formatting:
void fooWithAVeryLongParamList(
int firstParameter,
int secondParameter
int lastParameter)
{
object.alsoThisDoenstFitSoIBreakImmidiatly(
firstParameter,
secondParameter,
lastParameter);
}
Patch by Jean-Philippe Dufraigne, thank you.
llvm-svn: 255486
before it is not a closing parenthesis.
Otherwise, this frequently leads to "hanging" indents that users
perceive as "weird".
Before:
return !soooooooooooooome_map.insert(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.second;
After:
return !soooooooooooooome_map
.insert(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.second;
llvm-svn: 254933
This has seen quite some usage and I am not aware of any issues. Also
add a style option to enable/disable include sorting. The existing
command line flag can from now on be used to override whatever is set
in the style.
llvm-svn: 253202
Correct handling for C++17 inline namespaces. We would previously fail to
identify the inline namespaces as a namespace name since multiple ones may be
concatenated now with C++17.
llvm-svn: 251690
Specifically, don't wrap between the {} of an empty constructor if the
"}" falls on column 81 and ConstructorInitializerAllOnOneLineOrOnePerLine
is set.
llvm-svn: 251406
Summary:
If this option is set, clang-format will always insert a line wrap, e.g.
before the first parameter of a function call unless all parameters fit
on the same line. This obviates the need to make a decision on the
alignment itself.
Use this style for Google's JavaScript style and add some minor tweaks
to correctly handle nested blocks etc. with it. Don't use this option
for for/while loops.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D14104
llvm-svn: 251405
Fixes this bug: https://llvm.org/bugs/show_bug.cgi?id=24504
TokenAnnotator::spaceRequiredBetween was handling TT_ForEachMacro but
not TT_ObjCForIn, so lines that look like:
for (id nextObject in (NSArray *)myArray)
would incorrectly turn into:
for (id nextObject in(NSArray *)myArray)
Patch by Kent Sutherland, thank you.
llvm-svn: 249553
aligning assignments.
This was done correctly when aligning the declarations, but not when
aligning assignments.
FIXME: The code between assignments and declarations alignment is
roughly duplicated and
would benefit from factorization.
Bug 25090: https://llvm.org/bugs/show_bug.cgi?id=25090
Patch by Beren Minor. Thank you.
llvm-svn: 249552
This was made much easier by introducing an IncludeCategory struct to
replace the previously used std::pair.
Also, cleaned up documentation and added examples.
llvm-svn: 249392
This allows clang-format to align identifiers in consecutive
declarations. This is useful for increasing the readability of the code
in the same way the alignment of assignations is.
The code is a slightly modified version of the consecutive assignment
alignment code. Currently only the identifiers are aligned, and there is
no support of alignment of the pointer star or reference symbol.
The patch also solve the issue of alignments not being possible due to
the ColumnLimit for both the existing AlignConsecutiveAligments and the
new AlignConsecutiveDeclarations.
Patch by Beren Minor, thank you.
Review: http://reviews.llvm.org/D12362
llvm-svn: 248999
control the individual braces. The existing choices for brace wrapping
are now merely presets for the different flags that get expanded upon
calling the reformat function.
All presets have been chose to keep the existing formatting, so there
shouldn't be any difference in formatting behavior.
Also change the dump_format_style.py to properly document the nested
structs that are used to keep these flags discoverable among all the
configuration flags.
llvm-svn: 248802
It wasn't correctly handling this case:
int oneTwoThree = 123;
int oneTwo = 12;
method();
Review: http://reviews.llvm.org/D12369
Patch by Beren Minor. Thank you!
llvm-svn: 248254
Before:
DEPRECATED("Use NewClass::NewFunction instead.") int OldFunction(
const string ¶meter) {}
Could not be formatted at all, as clang-format would both require and
disallow the break before "int".
llvm-svn: 245846
This is a bit of a step back of what we did in r222531, as there are
some corner cases in C++, where this kind of formatting is really bad.
Example:
Before:
virtual aaaaaaaaaaaaaaaa(std::function<bool()> IsKindWeWant = [&]() {
return true;
}, aaaaa aaaaaaaaa);
After:
virtual aaaaaaaaaaaaaaaa(std::function<bool()> IsKindWeWant =
[&]() { return true; },
aaaaa aaaaaaaaa);
The block formatting logic in JavaScript will probably go some other changes,
too, and we'll potentially be able to make the rules more consistent again. For
now, this seems to be the best approach for C++.
llvm-svn: 245694
Summary:
Add brace style `BS_WebKit` as described on https://www.webkit.org/coding/coding-style.html:
* Function definitions: place each brace on its own line.
* Other braces: place the open brace on the line preceding the code block; place the close brace on its own line.
Set brace style used in `getWebKitStyle()` to the newly added `BS_WebKit`.
Reviewers: djasper, klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D11837
llvm-svn: 244446
__attribute__ was treated as the name of a function definition, with the
tokens in parentheses being the parameter list. This formats incorrectly
with AlwaysBreakAfterDefinitionReturnType. Fix it by treating
__attribute__ like decltype.
Patch by Strager Neds, thank you.
llvm-svn: 241439
The MacroBlockBegin and MacroBlockEnd options make matching macro identifiers
behave like '{' and '}', respectively, in terms of indentation.
Mozilla code, for example, uses several macros that begin and end a scope.
Previously, Clang-Format removed the indentation resulting in:
MACRO_BEGIN(...)
MACRO_ENTRY(...)
MACRO_ENTRY(...)
MACRO_END
Now, using the options
MacroBlockBegin: "^[A-Z_]+_BEGIN$"
MacroBlockEnd: "^[A-Z_]+_END$"
will yield the expected result:
MACRO_BEGIN(...)
MACRO_ENTRY(...)
MACRO_ENTRY(...)
MACRO_END
Differential Revision: http://reviews.llvm.org/D10840
llvm-svn: 241363
Among other things, this makes clang-format understand arbitrary blocks
embedded in them, such as:
SomeFunction({MACRO({ return output; }), b});
where MACRO could e.g. expand to a lambda.
llvm-svn: 241059
Format @autoreleasepool properly for the Attach brace style
by recognizing @autoreleasepool as a block introducer.
Patch from Strager Neds!
http://reviews.llvm.org/D10372
llvm-svn: 240896
conservative.
In particular, this fixes an unwanted corner case.
Before:
string s =
someFunction("aaaa"
"bbbb");
After:
string s = someFunction(
"aaaa"
"bbbb");
llvm-svn: 240129
It was a bit too aggressive.
With this patch, we keep on breaking here:
aaaaaaaaaaaaa(aaaaaaa,
"aaaaaaa"
"bbbbbbb");
But don't break in:
aaaaaaaaaaaaa(aaaaaaa, aaaaaaaa("aaaaaaa"
"bbbbbbb"));
llvm-svn: 240024
In essence this is meant to consistently indent multiline strings by a
fixed amount of spaces from the start of the line. Don't do this in
cases where it wouldn't help anyway.
Before:
someFunction(aaaaa,
"aaaaa"
"bbbbb");
After:
someFunction(aaaaa, "aaaaa"
"bbbbb");
llvm-svn: 240004
Before:
int c = []() -> int *{ return 2; }();
After:
int c = []() -> int * { return 2; }();
Based on patch by James Dennett (http://reviews.llvm.org/D10410), thank you!
llvm-svn: 239600
The following example used to crash clang-format.
#define a\
/**/}
Adjusting the indentation level cache for the line starting with the
comment would lead to an out-of-bounds array read.
llvm-svn: 239521
Before clang-format would e.g. add a space into
#define Q_FOREACH(x, y)
which turns this into a non-function-like macro.
Patch by Strager Neds, thank you!
llvm-svn: 239513
Before:
template <typename T>
auto aaaaaaaaaaaaaaaaaaaaaa(T t) -> decltype(eaaaaaaaaaaaaaaa<T>(t.a)
.aaaaaaaa());
After:
template <typename T>
auto aaaaaaaaaaaaaaaaaaaaaa(T t)
-> decltype(eaaaaaaaaaaaaaaa<T>(t.a).aaaaaaaa());
Also add a test case for a difficult template parsing case I stumbled accross.
Needs fixing.
llvm-svn: 239149
method expressions and array literals. They should not bind stronger
than regular parentheses or the braces of braced lists.
Specific test case in JavaScript:
Before:
var aaaaa: List<
SomeThing> = [new SomeThingAAAAAAAAAAAA(), new SomeThingBBBBBBBBB()];
After:
var aaaaa: List<SomeThing> = [
new SomeThingAAAAAAAAAAAA(),
new SomeThingBBBBBBBBB()
];
llvm-svn: 238400
instead of BinPackParameters. Braced lists are used as constructor
calls in many places and so the bin-packing should follow what is done
for other calls and not what is done for function declarations.
llvm-svn: 238184
This fixes a case where the column limit was incorrectly calculated
leading to a macro like this:
#define A \
[] { \
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx( \
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx); \
}
exceeding the column limit.
llvm-svn: 238182
"void (*my_function)(void)" should become "void (*my_function) (void)" when
SpaceBeforeParens is set to 'Always'
Differential Revision: http://reviews.llvm.org/D9835
llvm-svn: 237704
Before:
for (SmallVectorImpl<TemplateIdAnnotationn *>::iterator I =
Container.begin(),
E = Container.end();
I != E; ++I)
After:
for (SmallVectorImpl<TemplateIdAnnotationn *>::iterator
I = Container.begin(),
E = Container.end();
I != E; ++I)
This fixes llvm.org/PR23544.
llvm-svn: 237688
Before:
[call aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.
aaaaaaaa];
After:
[call aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa
.aaaaaaaa];
This merely papers over the fact that we aren't parsing ObjC method calls
correctly. Also, the indentation is weird.
llvm-svn: 237681
Before:
class C : test {
class D : test{void f(){int i{2};
}
}
;
}
;
After:
class C : test {
class D : test {
void f() { int i{2}; }
};
};
llvm-svn: 237569
Before:
ASSERT("aaaaaaaaaaaaaaa")
<< aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
After:
ASSERT("aaaaaaaaaaaaaaa") << aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
Also cleanup implementation a bit and only mark closing parenthesis of
these annotations.
llvm-svn: 237567
Generally, clang-format tries to keep label-value pairs on a single
line for stream operators. However, we should not do that if there is
just a single such pair, as that doesn't help much.
Before:
llvm::errs() << "aaaaaaaaaaaa: " << aaaaaaa(aaaaaaaaa,
aaaaaaaaa);
After:
llvm::errs() << "aaaaaaaaaaaa: "
<< aaaaaaa(aaaaaaaaa, aaaaaaaaa);
Also remove old test case that was testing actual behavior any more.
llvm-svn: 237535
comments. At some point, we might to want to a layout with a different
number of columns instead, but at the moment, this causes more
confusion than it's worth.
llvm-svn: 237427
before binary/ternary operators.
Basically, it doesn't seem right to indent a nested block aligned to a
binary or ternary operator.
Before:
int i = aaaaaa ? 1 //
: [] {
return 2; //
}();
llvm::errs() << "number of twos is "
<< std::count_if(v.begin(), v.end(), [](int x) {
return x == 2; // force break
});
After:
int i = aaaaaa ? 1 //
: [] {
return 2; //
}();
llvm::errs() << "number of twos is "
<< std::count_if(v.begin(), v.end(), [](int x) {
return x == 2; // force break
});
llvm-svn: 237263
Daniel Jasper