| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't allow the RHS of an operator to be split over multiple
lines unless there is a line-break right after the operator.
Before:
if (aaaa && bbbbb || // break
cccc) {
}
After:
if (aaaa &&
bbbbb || // break
cccc) {
}
In most cases, this seems to increase readability.
llvm-svn: 205527
|
|
|
|
| |
llvm-svn: 205526
|
|
|
|
|
|
|
|
|
|
| |
Before:
MACRO(auto * a);
After:
MACRO(auto *a);
llvm-svn: 205517
|
|
|
|
|
|
|
|
| |
This fixes llvm.org/PR17242.
Patch by Brian Green, thank you!
llvm-svn: 205307
|
|
|
|
| |
llvm-svn: 205193
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
#define A \
int i; /*a*/ \
int jjj; /*b*/
After:
#define A \
int i; /*a*/ \
int jjj; /*b*/
llvm-svn: 205011
|
|
|
|
|
|
| |
We don't want to deviate from clang's standard terminology.
llvm-svn: 204997
|
|
|
|
| |
llvm-svn: 204990
|
|
|
|
|
|
|
| |
Now correctly formats:
foo<true && false>();
llvm-svn: 204950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While these might make sense for some rule (e.g. break after multi-line
operand), they generally appear ugly and confusing.
Before:
fffffffffff(R\"x(
multiline raw string literal xxxxxxxxxxxxxx
)x\" + bbbbbb)
After:
fffffffffff(R\"x(
multiline raw string literal xxxxxxxxxxxxxx
)x\" +
bbbbbb)
llvm-svn: 204937
|
|
|
|
|
|
| |
No functional changes intended.
llvm-svn: 204930
|
|
|
|
|
|
|
|
| |
Clang-format now correctly formats:
some_type<a * b> v;
template <bool a, bool b> typename enabled_if<a && b>::type f() {}
llvm-svn: 204913
|
|
|
|
| |
llvm-svn: 204905
|
|
|
|
|
|
|
|
|
|
| |
Before:
STATIC_ASSERT((a &b) == 0);
After:
STATIC_ASSERT((a & b) == 0);
llvm-svn: 204709
|
|
|
|
|
|
|
| |
This unbreaks polly-formatting-tests and we can make a decision for
LLVM style independently.
llvm-svn: 204467
|
|
|
|
| |
llvm-svn: 204462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They very rarely aid readability.
Formatting:
void f() {
if (a) {
f();
}
}
Now leads to:
void f() {
if (a) {
f();
}
}
llvm-svn: 204460
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
vector<int> x{1, 2, 3, 4, };
After:
vector<int> x{
1, 2, 3, 4,
};
This fixes llvm.org/PR18519.
llvm-svn: 204458
|
|
|
|
| |
llvm-svn: 204457
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Formatting:
SomeFunction(a,
b, // comment
c);
Before:
SomeFunction(a, b, // comment
c);
After:
SomeFunction(a,
b, // comment
c);
llvm-svn: 204456
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D3110
llvm-svn: 204156
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to not resetting the fake rparen data on the token when iterating
over annotated lines, we would pop the last element of the paren stack.
This patch fixes the underlying root cause, and makes the code more
robust against similar problems in the future:
- reset the first token when iterating on the same annotated lines due
to preprocessor branches
- never pop the last element from the paren stack, so we do not crash,
but rather incorrectly format
- add assert()s so we can figure out if our assumptions are violated
llvm-svn: 204140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@{
NSFontAttributeNameeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee :
regularFont,
};
After:
@{
NSFontAttributeNameeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee :
regularFont,
};
llvm-svn: 204041
|
|
|
|
|
|
| |
class.
llvm-svn: 203999
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This check hints clang analyzer, that FormatTok may be null, and it
reports a null pointer dereference error:
http://buildd-clang.debian.net/scan-build/report-827c64.html#Path28
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D3040
llvm-svn: 203800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was leading to bad formatting, e.g.:
Before:
f(^{
@autoreleasepool {
if (a) {
g();
}
}
});
After:
f(^{
@autoreleasepool {
if (a) {
g();
}
}
});
llvm-svn: 203777
|
|
|
|
|
|
|
|
|
|
| |
Caused by unknown tokens (e.g. "\n") not properly updating the state.
Example:
const char* c = STRINGIFY(
\na : b);
llvm-svn: 203645
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
auto aaaaaaaa = [](int i, // break
int j)
-> int {
return fffffffffffffffffffffffffffffffffffffff(i * j);
};
After:
auto aaaaaaaa = [](int i, // break
int j) -> int {
return fffffffffffffffffffffffffffffffffffffff(i * j);
};
llvm-svn: 203562
|
|
|
|
|
|
|
|
|
|
| |
Before:
int i = (*b)[a] -> f();
After:
int i = (*b)[a]->f();
llvm-svn: 203557
|
|
|
|
|
|
|
|
|
|
| |
Before:
int i = a[a][a] -> f();
After:
int i = a[a][a]->f();
llvm-svn: 203556
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
void f() {
MACRO((const AA & a) { return 1; });
}
After:
void f() {
MACRO((const AA &a) { return 1; });
}
llvm-svn: 203551
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
void f() {
bar([]() {}// Does not respect SpacesBeforeTrailingComments
);
}
After:
void f() {
bar([]() {} // Does not respect SpacesBeforeTrailingComments
);
}
This fixes llvm.org/PR19017.
llvm-svn: 203466
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If we need to break the second line here:
// something: aaaaa aaaaa aaaaaa aaaaa aaaaa
// aaaaa aaaaa aaaaaa aaaaa aaaaa aaaaa
with the patch it will be turned to
// something: aaaaa aaaaa aaaaaa aaaaa aaaaa
// aaaaa aaaaa aaaaaa aaaaa aaaaa
// aaaaa
instead of
// something: aaaaa aaaaa aaaaaa aaaaa aaaaa
// aaaaa aaaaa aaaaaa aaaaa aaaaa
// aaaaa
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2988
llvm-svn: 203458
|
|
|
|
|
|
|
|
|
|
| |
Before:
int c = []()->int { return 2; }();
After:
int c = []() -> int { return 2; }();
llvm-svn: 203452
|
|
|
|
| |
llvm-svn: 203389
|
|
|
|
|
|
| |
This compiles cleanly with lldb/lld/clang-tools-extra/llvm.
llvm-svn: 203279
|
|
|
|
|
|
| |
This is a precursor to moving to std::unique_ptr.
llvm-svn: 203275
|
|
|
|
| |
llvm-svn: 203123
|
|
|
|
|
|
|
|
|
| |
init list formatting. This suggestion has now gone into the LLVM coding
standards, and is particularly relevant now that we're using C++11.
Updated a really ridiculous number of tests to reflect this change.
llvm-svn: 202637
|
|
|
|
| |
llvm-svn: 202238
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
introduce CLANG_TABLEGEN_TARGETS.
This does;
- clang_tablegen() adds each tblgen'd target to global property CLANG_TABLEGEN_TARGETS as list.
- List of targets is added to LLVM_COMMON_DEPENDS.
- all clang libraries and targets depend on generated headers.
You might wonder this would be regression, but in fact, this is little loss.
- Almost all of clang libraries depend on tblgen'd files and clang-tblgen.
- clang-tblgen may cause short stall-out but doesn't cause unconditional rebuild.
- Each library's dependencies to tblgen'd files might vary along headers' structure.
It made hard to track and update *really optimal* dependencies.
Each dependency to intrinsics_gen and ClangSACheckers is left as DEPENDS.
llvm-svn: 201842
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generally people seem to prefer wrapping the first function parameter
over wrapping the trailing tokens "const", "override" and "final". This
does not extend to function-like annotations and probably not to other
non-standard annotations.
Before:
void someLongFunction(int SomeLongParameter)
const { ... }
After:
void someLongFunction(
int SomeLongParameter) const { ... }
llvm-svn: 201504
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
template <class R, class C>
struct Aaaaaaaaaaaaaaaaa<R (C::*)(int)
const> : Aaaaaaaaaaaaaaaaa<R (C::*)(int)> {};
After:
template <class R, class C>
struct Aaaaaaaaaaaaaaaaa<R (C::*)(int) const>
: Aaaaaaaaaaaaaaaaa<R (C::*)(int)> {};
llvm-svn: 201424
|
|
|
|
|
|
|
| |
E.g.:
Foo([]()->std::vector<int> { return { 2 }; }());
llvm-svn: 201139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
auto result = SomeObject
// Calling someFunction on SomeObject
.someFunction();
After:
auto result = SomeObject
// Calling someFunction on SomeObject
.someFunction();
llvm-svn: 201138
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before (81 columns):
#define A \
void aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa() { return aaaaaaaa; } \
int i;
After:
#define A \
void aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa() { \
return aaaaaaaa; \
} \
int i;
llvm-svn: 200974
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
for (aaaaaaaaa aaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaa.aaaaaaaaaaaa()
.aaaaaaaaa()
.a()) {
}
After:
for (aaaaaaaaa aaaaaaaaaaaaaaaaaaaaa :
aaaaaaaaaaaa.aaaaaaaaaaaa().aaaaaaaaa().a()) {
}
llvm-svn: 200968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It seems like most people see unary operators more like part of the
subsequent identifier and find relative indentation odd.
Before:
aaaaaaaaaa(!aaaaaaaaaa( // break
aaaaa));
After:
aaaaaaaaaa(!aaaaaaaaaa( // break
aaaaa));
llvm-svn: 200840
|
|
|
|
| |
llvm-svn: 200652
|
|
|
|
|
|
|
| |
Before, this would lead to a crash:
f('', true);
llvm-svn: 200540
|