Include sorting generally can break .cc files, especially on Windows. Make
this opt-in for Chromium style to give us some more time to roll this out.
(Given that the Google style guide is used by many companies, some of them
probably writing code on Windows, one could argue this should be opt-in in
general...)
llvm-svn: 256288
initializers. For now, only use it for 20 items or more. Otherwise,
clang-format formats these one-per-line and thus increases the vertical
code size a lot.
llvm-svn: 256246
Before, the first (non-system) header in a file was considered to be
the main include. This is conservative as it makes clang-format change
the #include order less often. Instead implement some basic usage of
the filename itself. With this patch, clang-format considers every
header to be a main include if the header file's basename is a prefix
to the filename the #include is in.
llvm-svn: 256148
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
Specifically, it is sometimes necessary to keep certain #includes as
the first #include, even before the main #include for a .cc file.
Switching the category to be signed instead of unsigned isn't ideal,
but it seems as good of an option as any and is fully backwards
compatible.
llvm-svn: 255757
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
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
unaffected lines with incorrect initial indent.
Starting from:
namespace {
int i; // There shouldn't be indentation here.
int j; // <- call clang-format on this line.
}
Before:
namespace {
int i;
int j;
}
After:
namespace {
int i;
int j;
}
llvm-svn: 251824
Summary:
With this change, clang-format stops formatting when either it leaves
the current scope or when it comes back to the initial scope after
going into a nested one.
Reviewers: klimek
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D14213
llvm-svn: 251760
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
Summary: This is especially important so that if a change is solely inserting a block around a few statements, clang-format-diff.py will still clean up and add indentation to the inner parts.
Reviewers: klimek
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D14105
llvm-svn: 251474
With more complex structures in C++ Lambdas and JavaScript function
literals, the old value was simply to small. However, this is a
temporary solution, I need to look at this more closely a) to find a
fundamentally better approach and b) to look at whether the more recent
usage of NoLineBreak makes us visit stuff in an unfortunate order
where clang-format waste many states in dead ends.
llvm-svn: 251463
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
clang accepts both #include and #import for includes (the latter having an
implicit header guard). Let clang-format interleave both types if
--sort-includes is passed. #import is used frequently in Objective-C code.
http://reviews.llvm.org/D13853
llvm-svn: 250909
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
If a RegExp contains a character group with a quote (/["]/), the
trailing end of it is first tokenized as a string literal, which leads
to the merging code seeing an unbalanced bracket.
This change parses regex literals from the left hand side. That
simplifies the parsing code and also allows correctly handling escapes
and character classes, hopefully correctly parsing all regex literals.
Patch by Martin Probst, thank you.
Review: http://reviews.llvm.org/D13765
llvm-svn: 250648
Slashes in regular expressions do not need to be escaped and do not
terminate the regular expression even without a preceding backslash.
Patch by Martin Probst. Thank you.
llvm-svn: 250009
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
Apart from being cleaner this also means that clang-format no longer has
access to the host file system. This isn't necessary because clang-format
never reads includes :)
Includes minor tweaks and bugfixes found in the VFS implementation while
running clang-format tests.
llvm-svn: 249385
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
llvm-svn: 249279
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
Recognize the main module header as well as different #include categories.
This should now mimic the behavior of llvm/utils/sort_includes.py as
well as clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.cpp very
closely.
llvm-svn: 248782
JavaScript allows keywords to appear in IdenfierName positions, e.g.
fields, or object literal members, but not as plain identifiers.
Patch by Martin Probst. Thank you!
llvm-svn: 248714
To implement this nicely, add a function that merges two sets of
replacements that are meant to be done in sequence. This functionality
will also be useful for other applications, e.g. formatting the result
of clang-tidy fixes.
llvm-svn: 248367
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
We prefer setting these in our .clang-format file as the macros change over
time. (Also, the code was setting MacroBlockBegin twice and didn't set
MacroBlockEnd, so it wasn't doing what it tried to do anyways.)
llvm-svn: 248205
Seems it broke the Polly build.
From http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-fast/builds/11687/steps/compile/logs/stdio:
In file included from /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/lib/TableGen/Record.cpp:14:0:
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:369:3: error: looser throw specifier for 'virtual llvm::TypedInit::~TypedInit()'
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:270:11: error: overriding 'virtual llvm::Init::~Init() noexcept (true)'
llvm-svn: 247222
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
In proto, enum constants can contain complex options and should be
handled more like individual declarations.
Before:
enum Type {
UNKNOWN = 0 [(some_options) =
{
a: aa,
b: bb
}];
};
After:
enum Type {
UNKNOWN = 0 [(some_options) = {
a: aa,
b: bb
}];
};
llvm-svn: 242404
Before:
class Test {
aaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaa:
aaaaaaaaaaaaaaaaaaaaaaaa): aaaaaaaaaaaaaaaaaaaaaa {}
}
After:
class Test {
aaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaa: aaaaaaaaaaaaaaaaaaaaaaaa):
aaaaaaaaaaaaaaaaaaaaaa {}
}
llvm-svn: 241908
__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
Summary: This makes the Mozilla style defaults more compliant with the Mozilla style guide. A few options were removed in order to use the LLVM style defaults.
Differential Revision: http://reviews.llvm.org/D10771
llvm-svn: 240957
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
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
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
Before:
var func =
function() {
doSomething();
};
After:
var func =
function() {
doSomething();
};
This is a very narrow special case which fixes most of the discrepency
with what our users do. In the long run, we should try to come up with
a more generic fix for indenting these.
llvm-svn: 240014
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
This makes this consistent with non-typescript enums.
Also shuffle the language-dependent stuff in mustBreakBefore to a
single location.
Patch initiated by Martin Probst.
llvm-svn: 239894
Before, these would not properly detected because of the char/string
literal found when re-lexing after the first `:
var x = `'`; // comment with matching quote '
var x = `"`; // comment with matching quote "
llvm-svn: 239693
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
statement.
When an exported function would follow a class declaration, it would not
be recognized as a stand-alone function. That would then collapse the
following line with the current one, e.g.
class C {}
export function f() {} var x;
llvm-svn: 239592
In the long run, these two might be independent or we might to only
allow specific combinations. Until we have a corresponding request,
however, it is hard to do the right thing and choose the right
configuration options. Thus, just don't touch the options yet and
just modify the behavior slightly.
llvm-svn: 239531
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
assignments as enums.
Top level object literals are treated as enums, and their k/v pairs are put on
separate lines:
X.Y = {
A: 1,
B: 2
};
However assignments within blocks should not be affected:
function x() {
y = {a:1, b:2};
}
This change fixes the second case. Patch by Martin Probst.
llvm-svn: 239462
I have not succeeded in writing a proper test case for this yet and we
also need to solve the underlying fundamental problem of trying too
many combinations with nested blocks (basically this somewhat works
around our Dijkstra algorithm). Preventing this linebreak is good
anyways as usually the penalties never make us choose it (that's why I
can't create a test) and it also looks ugly.
Also cleaned up state comparison code that I discovered while hunting
this down.
llvm-svn: 239398
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
This is a more correct representation than using "Equality" introduced
in r238942 which was a quick fix to solve an actual regression.
According to the typescript spec, arrows behave like "low-precedence"
assignments.
Before:
var a = a.aaaaaaa((a: a) => aaaaaaaaaaaaaaaaaaaaa(bbbbbbbbb) &&
aaaaaaaaaaaaaaaaaaaaa(bbbbbbb));
After:
var a = a.aaaaaaa((a: a) => aaaaaaaaaaaaaaaaaaaaa(bbbbbbbbb) &&
aaaaaaaaaaaaaaaaaaaaa(bbbbbbb));
llvm-svn: 239137
Before:
var aaaaa: List<SomeThing> = [
new SomeThingAAAAAAAAAAAA(),
new SomeThingBBBBBBBBB()
];
After:
var aaaaa: List<SomeThing> =
[new SomeThingAAAAAAAAAAAA(), new SomeThingBBBBBBBBB()];
llvm-svn: 238909
Before:
someFunction(() =>
{
doSomething(); // break
})
.doSomethingElse( // break
);
After:
someFunction(() => {
doSomething(); // break
})
.doSomethingElse( // break
);
This is still bad, but at least it is consistent with what we do for other
function literals. Added corresponding tests.
llvm-svn: 238736
Specifically adhere to LLVM Coding Standards (no 'else' after
return/break/continue) and remove yet another implementation of
paren counting. We already have enough of those in the
UnwrappedLineParser.
No functional changes intended.
llvm-svn: 238672
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
A definintion like this could not be formatted at all:
constructor({aa}: {
aa?: string,
aaaaaaaa?: string,
aaaaaaaaaaaaaaa?: boolean,
aaaaaa?: List<string>
}) {
}
llvm-svn: 238291
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
Specifically, don't add a space before it.
Before:
someFunction(... a);
var x = [1, 2, ... a];
After:
someFunction(...a);
var x = [1, 2, ...a];
llvm-svn: 238183
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
Assigns a token type (TT_JsFatArrow) to => tokens, and uses that to
more easily recognize and format fat arrow functions.
Improves function parsing to better recognize formal parameter
lists and return type declarations.
Recognizes arrow functions and parse function bodies as child blocks.
Patch by Martin Probst.
llvm-svn: 237895
"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