In particular, make it more expensive than breaking after the return
type of a function definition/declaration.
Before:
template <typename T>
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaa<
T>::aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaa);
After:
template <typename T>
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaa<T>::aaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@260497 91177308-0d34-0410-b5e6-96231b3b80d8
After reading the style guides again, they don't actually say how to
pack or not pack array literals. Based on some user reports, array
initializers can unnecessarily get quite long if they contain many
small elements. Array literals with trailing commas are still formatted
one per line so that users have a way to opt out of the packing.
Before:
var array = [
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa
];
After:
var array = [
aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa,
aaaaaa, aaaaaa
];
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257615 91177308-0d34-0410-b5e6-96231b3b80d8
As soon as a comment had whitespace changes inside of the token, we
couldn't identify the whole comment as a trailing comment anymore and
alignment stopped working. Add a new boolean to Change for this special
case and fix trailing comment identification to use it.
This also changes WhitespaceManager to sum the length of all Changes
inside of a token into the first Change.
Before this fix
int xy; // a
int z; //b
became
int xy; // a
int z; // b
with this patch we immediately get to:
int xy; // a
int z; // b
Differential Revision: http://reviews.llvm.org/D16058
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257341 91177308-0d34-0410-b5e6-96231b3b80d8
r257257 change the way clang-format enforces line breaks after a
templated type has been line-wrapped. This was to fix an incorrect line
break if BinPackParameters is set to false. However, it also leads to
an unwanted line break in a different case. Thus, for now, only do this
when BinPackParameters is false. This isn't ideal yet, but helps us
until we have a better solution.
With BinPackParameters:
Before:
void fffffffffff(aaaaaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaa> aaaaaaaaaa);
After:
void fffffffffff(
aaaaaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaa>
aaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257325 91177308-0d34-0410-b5e6-96231b3b80d8
r256750 has been leading to an undesired behavior:
aaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaa.aaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
This change increases penalty for wrapping before member accesses that aren't
calls. Thus, this is again formatted as (as it has been before r256750):
aaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaa.aaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@256830 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@255486 91177308-0d34-0410-b5e6-96231b3b80d8
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;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@254933 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
MACRO(> );
After:
MACRO(>);
Not overly important, but easy and good for symmetry reasons :-).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253669 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253202 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251690 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, don't wrap between the {} of an empty constructor if the
"}" falls on column 81 and ConstructorInitializerAllOnOneLineOrOnePerLine
is set.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251406 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251405 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249553 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249552 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
inline A operator^(const A &lhs, const A &rhs) {} int i;
After:
inline A operator^(const A &lhs, const A &rhs) {}
int i;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249517 91177308-0d34-0410-b5e6-96231b3b80d8
This was made much easier by introducing an IncludeCategory struct to
replace the previously used std::pair.
Also, cleaned up documentation and added examples.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249392 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248999 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248802 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
SomeType MemberFunction(const Deleted &)&;
After:
SomeType MemberFunction(const Deleted &) &;
Seems to be much more common.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245934 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245846 91177308-0d34-0410-b5e6-96231b3b80d8
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++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245694 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@244446 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would format
call(
p);
as
call(
p);
with MaxEmptyLinesToKeep == 0.
Now we format it as:
call(p);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243429 91177308-0d34-0410-b5e6-96231b3b80d8
__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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241439 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241363 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241059 91177308-0d34-0410-b5e6-96231b3b80d8
conservative.
In particular, this fixes an unwanted corner case.
Before:
string s =
someFunction("aaaa"
"bbbb");
After:
string s = someFunction(
"aaaa"
"bbbb");
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240129 91177308-0d34-0410-b5e6-96231b3b80d8
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"));
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240024 91177308-0d34-0410-b5e6-96231b3b80d8
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");
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@240004 91177308-0d34-0410-b5e6-96231b3b80d8
This is a first step for splitting the huge FormatTest.cpp into separate
files to make it easier to find specific tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239730 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239521 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239513 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239149 91177308-0d34-0410-b5e6-96231b3b80d8
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()
];
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238400 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238184 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238182 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237688 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237681 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
class C : test {
class D : test{void f(){int i{2};
}
}
;
}
;
After:
class C : test {
class D : test {
void f() { int i{2}; }
};
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237569 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
ASSERT("aaaaaaaaaaaaaaa")
<< aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
After:
ASSERT("aaaaaaaaaaaaaaa") << aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
Also cleanup implementation a bit and only mark closing parenthesis of
these annotations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237567 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237535 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237427 91177308-0d34-0410-b5e6-96231b3b80d8
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
});
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237263 91177308-0d34-0410-b5e6-96231b3b80d8
It was fooled by the comment.
Before:
SOME_UNRELATED_MACRO
/*static*/ int i;
After:
SOME_UNRELATED_MACRO
/*static*/ int i;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237246 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
a) Pull out a class LevelIndentTracker whose responsibility is to keep track
of the indent of levels across multiple annotated lines.
b) Put all responsibility for merging lines into the LineJoiner; make the
LineJoiner iterate over the lines so we never operate on a line that might
be merged later; this makes the interface safer to use.
c) Move formatting of the end-of-file whitespace into formatFirstToken.
Fix bugs that became obvious after the refactoring:
1. We would not format lines with offsets correctly inside nested blocks if
only the outer expression was affected:
int x = s({ // clang-format only this line
class X {
public:
// ^ this starts at the non-modified indnent level; previously we would
// not fix this, now we correctly outdent it.
void f();
};
});
2. We would incorrectly align comments across lines that do not have comments
for lines with nested blocks:
int expression; // with comment
int x = s({
int y; // comment
int z; // we would incorrectly align this comment with the comment on
// 'expression'
});
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237104 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, calculate the deviation between the shortest and longest
element (which is used to prevent excessive whitespace) per column, not
overall. This automatically handles the corner cases of a single column
and a single row so that the actualy implementation becomes simpler.
Before:
vector<int> x = {1,
aaaaaaaaaaaaaaaaaaaaaa,
2,
bbbbbbbbbbbbbbbbbbbbbb,
3,
cccccccccccccccccccccc};
After:
vector<int> x = {1, aaaaaaaaaaaaaaaaaaaaaa,
2, bbbbbbbbbbbbbbbbbbbbbb,
3, cccccccccccccccccccccc};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236992 91177308-0d34-0410-b5e6-96231b3b80d8
Some compilers ignore everything after a semicolon in such inline asm
blocks and thus, the closing brace must not be moved to the previous
line.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236946 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents clang-format from inadvertently joining stuff into macro
definitions as reported in llvm.org/PR23466.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236944 91177308-0d34-0410-b5e6-96231b3b80d8
In particular:
* If the difference between the longest and shortest element, we copped
out of column format completely. Now, we instead allow to arrange
these in a single column, essentially enforcing a one-per-line format.
* Allow column layout even if there are braced lists. Especially, if
there are many short lists, this can be beneficial. The bad case,
where there is a long nested init list is usually caught as we now
limit the length difference of the longest and shortest element.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236851 91177308-0d34-0410-b5e6-96231b3b80d8
E.g.:
default:;
This can be used to get around restrictions as to what can follow a
label. It fixes llvm.org/PR19648.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236604 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
[aaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaa:
aaaaaaaa aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
After:
[aaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaa:aaaaaaaa
aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
Note that this might now violate the column limit and we probably need an
alternative way of indenting these then. However, that is still strictly better
than the messy formatting that clang-format did before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236598 91177308-0d34-0410-b5e6-96231b3b80d8
In the process, fix an old todo that I don't really know how to write
tests for. The problem is that Clang's lexer creates very strange token
sequences for these. However, the new approach seems generally better
and easier to read so I am submitting it nonetheless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236589 91177308-0d34-0410-b5e6-96231b3b80d8
Splitting:
/**
* multiline block comment
*
*/
Before:
/**
* multiline block
*comment
*
*/
After:
/**
* multiline block
* comment
*
*/
The reason was that the empty line inside the comment (with just the "*") was
confusing the comment breaking logic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236573 91177308-0d34-0410-b5e6-96231b3b80d8
In Objective-C some style guides use a style where assignment operators are
aligned, in an effort to increase code readability. This patch adds an option
to the format library which allows this functionality. It is disabled by
default for all the included styles, so it must be explicitly enabled.
The option will change code such as:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
to:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
Patch by Matt Oakes. Thank you!
Accidentally reformatted all the tests...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236100 91177308-0d34-0410-b5e6-96231b3b80d8
This is now obvious as the pointer alignment behavior was changed.
Before (even with pointer alignment "Left"):
MACRO Constructor(const int &i) : a(a), b(b) {}
After:
MACRO Constructor(const int& i) : a(a), b(b) {}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235301 91177308-0d34-0410-b5e6-96231b3b80d8
space where we already had the flag ObjCSpaceBeforeProtocolList to
control it. I don't know what I was thinking.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@235076 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
for (int i = 0; i < in [a]; ++i) ..
After:
for (int i = 0; i < in[a]; ++i) ..
Also do some related cleanups.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@234980 91177308-0d34-0410-b5e6-96231b3b80d8
spacing also fixed by r230473.
The fix in r230473 was done to enable fixing the spacing for
std::function<void( int, int )>.
I did not realized that it also fixed this
issue. Since it is fairly different from
Deleted &operator=(const Deleted &)& = default;
fixed in r230473, it seems sensible to add the regression test for it.
Also cleaned up the test by removing duplicated code and comment, and kept
repeated test set consistent.
Result of running the new tests with r230473 backed out:
[ RUN ] FormatTest.ConfigurableSpacesInParentheses
Actual: "std::function<void(int, int)> callback;"
Expected: "std::function<void( int, int )> callback;"
Actual: "std::function<void( int, int )> callback;"
Expected: "std::function<void(int, int)> callback;"
Actual: "std::function<void( int, int ) > callback;"
Expected: "std::function<void(int, int)> callback;"
[ FAILED ] FormatTest.ConfigurableSpacesInParentheses (402 ms)
Result of new tests with r230473:
[ RUN ] FormatTest.ConfigurableSpacesInParentheses
[ OK ] FormatTest.ConfigurableSpacesInParentheses (209 ms)
Review: http://reviews.llvm.org/D7922
Patch by Jean-Philippe Dufraigne. Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@232632 91177308-0d34-0410-b5e6-96231b3b80d8
There was already a TODO to double-check whether the extra indenation
makes sense. A slightly different case reveals that it is actively harmful:
for (int i = 0; i < aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbbbb < ccccccccccccccc;
++i) {
}
Here (and it is probably not a totally infrequent case, it just works out that
"i < " is four spaces and so the four space extra indentation makes the
operator precedence confusing. So, this will now instead be formatted
as:
for (int i = 0; i < aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbbbb < ccccccccccccccc;
++i) {
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231461 91177308-0d34-0410-b5e6-96231b3b80d8
With incomplete code, we aren't guaranteed to generated changes for
every token. In that case, we need to assume that even the very first
change can continue a preprocessor directive and initialize values
accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@231066 91177308-0d34-0410-b5e6-96231b3b80d8
Seems like the most consistent thing to do and in multi-var DeclStmts,
it is especially important to point out that the */& bind to the
identifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230903 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
Aaaa aaaaaaaaaaa{
{
a, // +1 indent weird.
b, // trailing comma signals one per line.
}, // trailing comma signals one per line.
};
After:
Aaaa aaaaaaaaaaa{
{
a, // better!?
b, // trailing comma signals one per line.
}, // trailing comma signals one per line.
};
Interesting that this apparently was entirely untested :-(.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@230627 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents contracting:
auto lambda = []() {
int a = 2
#if A
+ 2
#endif
;
};
into:
auto lambda = []() { int a = 2
#if A + 2
#endif ; };
Which is obviously BAD.
This fixes llvm.org/PR22496.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228522 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
@try {
// ...
}
@finally {
// ...
}
Now:
@try {
// ...
} @finally {
// ...
}
This is consistent with how we format C++ try blocks and SEH try blocks.
clang-format not doing this before was an implementation oversight.
This is dependent on BraceBreakingStyle. The snippet above is with the
Attach style. Style Stroustrip for example still results in the "Before:"
snippet, which makes sense since other blocks (try, else) break after '}' too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228483 91177308-0d34-0410-b5e6-96231b3b80d8
This lets clang-format format
__try {
} __except(0) {
}
and
__try {
} __finally {
}
correctly. __try and __finally are keywords if `LangOpts.MicrosoftExt` is set,
so this turns this on. This also enables a few other keywords, but it
shouldn't overly perturb regular clang-format operation. __except is a
context-sensitive keyword, so `AdditionalKeywords` needs to be passed around to
a few more places.
Fixes PR22321.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@228148 91177308-0d34-0410-b5e6-96231b3b80d8
We did't properly mark all of an AnnotatedLine's children as finalized
and thus would reformat the same tokens in different branches of #if/#else
sequences leading to invalid replacements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@226930 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, adjust the leading "__asm {" and trailing "}" while still
leaving the assembly inside it alone.
This fixes llvm.org/PR22190.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225623 91177308-0d34-0410-b5e6-96231b3b80d8
This makes piped output easier to read in many instances.
Before:
llvm::errs() << aaaa << std::endl << bbbb << std::endl;
After:
llvm::errs() << aaaa << std::endl
<< bbbb << std::endl;
Also fix a few instance of "don't use else after return" as per the
coding standards.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225444 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents clang-format from moving/aligning the comment in the
snippet:
void f() {
int i; // some comment
// some unrelated comment
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@225352 91177308-0d34-0410-b5e6-96231b3b80d8
With alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
Without alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
This fixes llvm.org/PR21666.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@223117 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
Block b = ^int * (A * a, B * b) {}
After:
Block b = ^int *(A *a, B *b) {}
This fixed llvm.org/PR21619.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222639 91177308-0d34-0410-b5e6-96231b3b80d8
Previously this was only used for JavaScript.
Before:
functionCall({
int i;
int j;
},
aaaa, bbbb, cccc);
After:
functionCall({
int i;
int j;
}, aaaa, bbbb, cccc);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222531 91177308-0d34-0410-b5e6-96231b3b80d8
With AllowShortCaseLabelsOnASingleLine set to true:
This gets now left unchanged:
case 1:
// comment
return;
Whereas before it was changed into:
case 1: // comment return;
This fixes llvm.org/PR21630.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@222529 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
return a != b
// comment
? a
: a = a != b
// comment
? a =
b : a;
After:
return a != b
// comment
? a
: a = a != b
// comment
? a = b
: a;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221987 91177308-0d34-0410-b5e6-96231b3b80d8
namespace blocks act as if KeepEmptyLinesAtTheStartOfBlocks is always true,
and aren't collapsed to a single line even if they would fit. Do the same
for extern "C" blocks.
Before,
extern "C" {
void ExternCFunction();
}
was collapsed into `extern "C" { void ExternCFunction(); }`. Now it stays like
it was.
Fixes http://crbug.com/432640 and part of PR21419.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@221897 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Jasper