Though not completely identical, make former
IndentFunctionDeclarationAfterType change this flag for backwards
compatibility (it is somewhat close in meaning and better the err'ing on
an unknown config flag).
llvm-svn: 212597
Key changes:
- Correctly (well ...) distinguish function declarations and variable
declarations with ()-initialization.
- Don't indent when breaking function declarations/definitions after the
return type.
- Indent variable declarations and typedefs when breaking after the
type.
This fixes llvm.org/PR17999.
llvm-svn: 212591
Upon encountering a binary operator inside parentheses, assume that the
parentheses contain an expression.
Before:
MACRO('0' <= c&& c <= '9');
After:
MACRO('0' <= c && c <= '9');
llvm-svn: 212040
This worked initially but was broken by r210887.
Before:
function outer1(a, b) {
function inner1(a, b) { return a; } inner1(a, b);
} function outer2(a, b) { function inner2(a, b) { return a; } inner2(a, b); }
After:
function outer1(a, b) {
function inner1(a, b) { return a; }
inner1(a, b);
}
function outer2(a, b) {
function inner2(a, b) { return a; }
inner2(a, b);
}
Thanks to Adam Strzelecki for working on this.
llvm-svn: 212038
Thanks to David Blakie and Richard Smith for pointing out that we can retain the
-Wswitch coverage while avoiding the warning from GCC by pushing the unreachable
outside of the switch!
llvm-svn: 210812
tools/clang/lib/Basic/DiagnosticIDs.cpp: In function ‘clang::DiagnosticIDs::Level toLevel(clang::diag::Severity)’:
tools/clang/lib/Basic/DiagnosticIDs.cpp:382:1: warning: control reaches end of non-void function [-Wreturn-type]
tools/clang/lib/Format/Format.cpp: In member function ‘virtual std::string clang::format::ParseErrorCategory::message(int) const’:
tools/clang/lib/Format/Format.cpp:282:1: warning: control reaches end of non-void function [-Wreturn-type]
Add a default cases that asserts that we handle the severity, parse error.
llvm-svn: 210804
Before (JavaScript example, but can extend to other languages):
return {
a: 'E',
b: function() {
return function() {
f(); // This is wrong.
};
}
};
After:
return {
a: 'E',
b: function() {
return function() {
f(); // This is better.
};
}
};
llvm-svn: 210334
These are commonly used to structure things like enums or long braced
lists. There doesn't seem to be a good reason to have the behavior in
such structures be different from the behavior between statements.
llvm-svn: 210183
There is a pattern where evaluation order is used as control flow.
This patch special-cases a commonly occuring version of this pattern.
Before:
Aaaaa *aaa = nullptr;
// ...
aaa &&aaa->f();
After:
Aaaaa *aaa = nullptr;
// ...
aaa && aaa->f();
llvm-svn: 210017
Before (with just the right line length:
switch (a) {
case some_namespace::some_constant
:
return;
}
After:
switch (a) {
case some_namespace::
some_constant:
return;
}
llvm-svn: 209725
And "none" pseudo-style indicating that formatting should be not
applied.
(1) Using .clang-format with "DisableFormat: true" effectively prevents
formatting for all files within the folder containing such .clang-format
file.
(2) Using -fallback-style=none together with -style=file prevents
formatting when .clang-format is not found, which can be used in on-save
callback.
Patch by Adam Strzelecki. Thank you!
llvm-svn: 209446
Before:
template <int> struct A4 { A4() { }
};
After:
template <int i> struct A4 {
A4() {}
};
This fixes llvm.org/PR19813 (at least the part that isn't working as
intended).
llvm-svn: 209438
As the memory ownership is handled by the SpecificBumpPtrAllocator
anyway, there is no need to duplicate states when inserting them into
the Seen-set. This leads to an improvement of ~10% on the benchmark
formatting file.
No functional changes intended.
llvm-svn: 209422
Before:
var literal = 'hello ' + 'world';
After:
var literal = 'hello ' +
'world';
There is no reason to concatenated two string literals with a '+' unless
the line break is intended.
llvm-svn: 209413
Before:
int i{a *b};
After:
int i{a * b};
Also fix unrelated issue where braced init lists were counted as blocks
and prevented single-line functions.
llvm-svn: 209412
If simple (one-statement) blocks can be inlined, the length needs to be
calculated correctly.
Before (in JavaScript but this also affects lambdas, etc.):
var x = {
valueOf: function() { return 1; }
};
After:
var x = {valueOf: function() { return 1; }};
llvm-svn: 209410
Daniel Jasper