| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 182003
|
|
|
|
| |
llvm-svn: 182001
|
|
|
|
|
|
|
|
|
|
| |
This enables things like:
for (int &v : vec) v *= 2;
Enabled for Google style.
llvm-svn: 182000
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that several implementations go through the trouble of
setting up a SourceManager and Lexer and abstracting this into a
function makes usage easier.
Also abstracts SourceManager-independent ranges out of
tooling::Refactoring and provides a convenience function to create them
from line ranges.
llvm-svn: 181997
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
void f() {}
void g() {
} // comment
After:
void f() {}
void g() {} // comment
llvm-svn: 181996
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
f("a", "b"
"c");
After:
f("a", "b"
"c");
llvm-svn: 181980
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
namespace abc { class SomeClass; }
namespace def { void someFunction() {} }
After:
namespace abc {
class Def;
}
namespace def {
void someFunction() {}
}
Rationale:
a) Having anything other than forward declaration on the same line
as a namespace looks confusing.
b) Formatting namespace-forward-declaration-combinations different
from other stuff is inconsistent.
c) Wasting vertical space close to such forward declarations really
does not affect readability.
llvm-svn: 181887
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the long run, this will probably be better fixed by a proper
expression parser..
Before:
template <typename F>
Matcher(const Matcher<F> & Other,
typename enable_if_c < is_base_of<F, T>::value &&
!is_same<F, T>::value > ::type * = 0)
: Implementation(new ImplicitCastMatcher<F>(Other)) {}
After:
template <typename F>
Matcher(const Matcher<F> & Other,
typename enable_if_c<is_base_of<F, T>::value &&
!is_same<F, T>::value>::type * = 0)
: Implementation(new ImplicitCastMatcher<F>(Other)) {}
llvm-svn: 181884
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
template <typename A>
SomeLoooooooooooooooooooooongType<
typename some_namespace::SomeOtherType<A>::Type> Function() {}
After:
template <typename A>
SomeLoooooooooooooooooooooongType<
typename some_namespace::SomeOtherType<A>::Type>
Function() {}
llvm-svn: 181877
|
|
|
|
| |
llvm-svn: 181872
|
|
|
|
|
|
|
| |
We only ever implemented one and that one is not actually all that
helpful (e.g. gets incorrectly triggered by macros).
llvm-svn: 181871
|
|
|
|
|
|
|
|
|
|
|
| |
The function type detection in r181438 and r181764 detected function
types too eagerly. This led to inconsistent formatting of inline
assembly and (together with r181687) to an incorrect formatting of calls
in macros.
Before: #define DEREF_AND_CALL_F(parameter) f (*parameter)
After: #define DEREF_AND_CALL_F(parameter) f(*parameter)
llvm-svn: 181870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
if (aaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
After:
if (aaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
llvm-svn: 181828
|
|
|
|
|
|
|
|
|
|
|
| |
We have been assuming that CharSourceRange::getTokenRange() by itself
expands a range until the end of a token, but in fact it only sets
IsTokenRange to true. Thus, we have so far only considered the first
character of the last token to belong to an unwrapped line. This
did not really manifest in symptoms as all edit integrations
expand ranges to fully lines.
llvm-svn: 181778
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before (in styles that allow it), clang-format would not merge an
if statement onto a single line, if only the second line was format
(e.g. in an editor integration):
if (a)
return; // clang-format invoked on this line.
With this patch, this gets properly merged to:
if (a) return; // ...
llvm-svn: 181770
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes indentation where there are for example multiple closing
parentheses after a string literal, and where those parentheses
run over the end of the line.
During testing this revealed a bug in the implementation of
breakProtrudingToken: we don't want to change the state if we didn't
actually do anything.
llvm-svn: 181767
|
|
|
|
|
|
| |
Before: A<sizeof (*x)> a;
After: A<sizeof(*x)> a;
llvm-svn: 181764
|
|
|
|
|
|
| |
[-Wconversion-null], introduced in r181326.
llvm-svn: 181761
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
#define A(X) \
"aaaaa" #X "bbbbbb" \
"ccccc"
After:
#define A(X) \
"aaaaa" #X "bbbbbb" \
"ccccc"
llvm-svn: 181732
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now support "Linux" and "Stroustrup" brace breaking styles, which
gets us one step closer to support formatting WebKit, KDE & Linux code.
Linux brace breaking style:
namespace a
{
class A
{
void f()
{
if (x) {
f();
} else {
g();
}
}
}
}
Stroustrup brace breaking style:
namespace a {
class A {
void f()
{
if (x) {
f();
} else {
g();
}
}
}
}
llvm-svn: 181700
|
|
|
|
|
|
| |
This is required for kernel linux kernel style formatting.
llvm-svn: 181693
|
|
|
|
|
|
|
|
| |
Fake parentheses (i.e. emulated parentheses used to correctly handle
binary expressions) used to prevent the optimization implemented in
r180264.
llvm-svn: 181692
|
|
|
|
|
|
|
| |
This is required for various styles that are for example based on
8-indent.
llvm-svn: 181690
|
|
|
|
|
|
|
|
|
| |
This seems to be the vastly more common case. If we find enough
examples to the contrary, we can make it smarter.
Before: #define MACRO void f(int * a)
After: #define MACRO void f(int *a)
llvm-svn: 181687
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise (when indenting from the wrapped -> or .), this looks
like a confusing indent.
Before:
aaaaaaa //
.aaaaaaa( //
aaaaaaa);
After:
aaaaaaa //
.aaaaaaa( //
aaaaaaa);
llvm-svn: 181595
|
|
|
|
|
|
|
|
| |
Thereby, the macro is consistently formatted (including the trailing
escaped newlines) even if clang-format is invoked only on single lines
of the macro.
llvm-svn: 181590
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adds actual config file reading to the clang-format utility.
Configuration file name is .clang-format. It is looked up for each input file
in its parent directories starting from immediate one. First found .clang-format
file is used. When using standard input, .clang-format is searched starting from
the current directory.
Added -dump-config option to easily create configuration files.
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits, jordan_rose, kimgr
Differential Revision: http://llvm-reviews.chandlerc.com/D758
llvm-svn: 181589
|
|
|
|
|
|
|
|
|
|
|
| |
Before, the actual operator of an overloaded operator declaration was
handled as a binary operator an thus, clang-format could not find valid
formattings for many examples, e.g.:
template <typename AAAAAAA, typename BBBBBBB>
AAAAAAA operator/(const AAAAAAA &a, BBBBBBB &b);
llvm-svn: 181585
|
|
|
|
|
|
|
|
| |
With style where the *s go with the type:
Before: typedef bool* (Class:: *Member)() const;
After: typedef bool* (Class::*Member)() const;
llvm-svn: 181439
|
|
|
|
|
|
| |
Before: int(S::*func)(void *);
After: int (S::*func)(void *);
llvm-svn: 181438
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the LHS of a binary expression is broken, clang-format should also
break after the operator as otherwise:
- The RHS can be easy to miss
- It can look as if clang-format doesn't understand operator precedence
Before:
bool aaaaaaaaaaaaaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa !=
bbbbbbbbbbbbbbbbbb && ccccccccc == ddddddddddd;
After:
bool aaaaaaaaaaaaaaaaaaaaa =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa != bbbbbbbbbbbbbbbbbb &&
ccccccccc == ddddddddddd;
As an additional note, clang-format would also be ok with the following
formatting, it just has a higher penalty (IMO correctly so).
bool aaaaaaaaaaaaaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa !=
bbbbbbbbbbbbbbbbbb &&
ccccccccc == ddddddddddd;
llvm-svn: 181430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaaa::
aaaaaaaa::
aaaaaaaa();
After:
aaaaaaaa::
aaaaaaaa::
aaaaaaaa();
The reason for the change is that:
a) we are not sure which is better
b) it is a really rare edge case
c) it simplifies the code
d) it currently causes problems with memoization
llvm-svn: 181421
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added parseConfiguration method, which reads FormatStyle from YAML
string. This supports all FormatStyle fields and an additional BasedOnStyle
field, which can be used to specify base style.
Reviewers: djasper, klimek
Reviewed By: djasper
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D754
llvm-svn: 181326
|
|
|
|
|
|
|
|
| |
With certain styles:
Before: delete* x;
After: delete *x;
llvm-svn: 181318
|
|
|
|
|
|
|
|
|
|
| |
LLVM/Clang basically don't use such comments and for Google-style,
include-lines are explicitly exempt from the column limit. Also, for
most cases, where the column limit is violated, the "better" solution
would be to move the comment to before the include, which clang-format
cannot do (yet).
llvm-svn: 181191
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang-format did not indent any declarations/definitions when breaking
after the type. With this change, it indents for all declarations but
does not indent for function definitions, i.e.:
Before:
const SomeLongTypeName&
some_long_variable_name;
typedef SomeLongTypeName
SomeLongTypeAlias;
const SomeLongReturnType*
SomeLongFunctionName();
const SomeLongReturnType*
SomeLongFunctionName() { ... }
After:
const SomeLongTypeName&
some_long_variable_name;
typedef SomeLongTypeName
SomeLongTypeAlias;
const SomeLongReturnType*
SomeLongFunctionName();
const SomeLongReturnType*
SomeLongFunctionName() { ... }
While it might seem inconsistent to indent function declarations, but
not definitions, there are two reasons for that:
- Function declarations are very similar to declarations of function
type variables, so there is another side to consistency to consider.
- There can be many function declarations on subsequent lines and not
indenting can make them harder to identify. Function definitions
are already separated by their body and not indenting
makes the function name slighly easier to find.
llvm-svn: 181187
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems to be more common in LLVM, Google and Chromium.
Before:
class AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA :
public BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
public CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC {
};
After:
class AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
: public BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
public CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC {
};
llvm-svn: 181183
|
|
|
|
|
|
| |
Before: template <class ... Ts> void Foo(Ts ... ts) { Foo(ts ...); }
After: template <class... Ts> void Foo(Ts... ts) { Foo(ts...); }
llvm-svn: 181182
|
|
|
|
|
|
| |
Before: for (int i = 0;(i < 10); ++i) {}
After: for (int i = 0; (i < 10); ++i) {}
llvm-svn: 181020
|
|
|
|
|
|
| |
Before: for (; a&& b;) {}
After: for (; a && b;) {}
llvm-svn: 181017
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Deeply nested expressions basically break clang-format's memoization.
This patch slightly improves the situations and makes expressions like
aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(
aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(
aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(
aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(
aaaaa(aaaaa())))))))))))))))))))))))))))))))))))))));
work.
llvm-svn: 180264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This enables formattings like:
#define A \
int aaaa; \
int b; \
int ccc; \
int dddddddddd;
Enabling this for Google/Chromium styles only as I don't know whether it
is desired for Clang/LLVM.
llvm-svn: 180253
|
|
|
|
|
|
|
|
|
|
|
| |
In the following snippet, clang-format incorrectly aligned the
trailing comment, when only the last line was formatted:
int aaaaaa; // comment
int b;
int c; // Formatting only this line moved this comment.
llvm-svn: 180173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
#if !defined(AAAAAAAAAAAAAAAA) && (defined CCCCCCCC || \
defined DDDDDDDD) && defined(BBBBBBBB)
After:
#if !defined(AAAAAAAAAAAAAAAA) && (defined CCCCCCCC || defined DDDDDDDD) && \
defined(BBBBBBBB)
This fixes llvm.org/PR15828.
llvm-svn: 180105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In Google style, constructor initializers need to be all on one line or
one initializer per line if that does not fit. Without this patch, this
non-bin-packing-behavior incorrectly extends to the parameters of the
initializers.
Before:
Constructor()
: aaaaa(aaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaa) {}
After:
Constructor()
: aaaaa(aaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaa) {}
llvm-svn: 180001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added BreakableLineComment, moved common code from
BreakableBlockComment to newly added BreakableComment. As a side-effect of the
rewrite, found another problem with escaped newlines and had to change
code which removes trailing whitespace from line comments not to break after
this patch.
Reviewers: klimek, djasper
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D682
llvm-svn: 179693
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do this in general, but missed a few cases.
Before:
void aaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, bbbb bbbb);
After:
void aaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
bbbb bbbb);
llvm-svn: 179570
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Both strings and block comments are broken into lines in
breakProtrudingToken. Logic specific for strings or block comments is abstracted
in implementations of the BreakToken interface. Among other goodness, this
change fixes placement of backslashes after a block comment inside a
preprocessor directive (see removed FIXMEs in unit tests).
The code is far from being polished, and some parts of it will be changed for
line comments support.
Reviewers: klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D665
llvm-svn: 179526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we'd only detect structural errors on the very first level.
This leads to incorrectly balanced braces not being discovered, and thus
incorrect indentation.
This change fixes the problem by:
- changing the parser to use an error state that can be detected
anywhere inside the productions, for example if we get an eof on
SOME_MACRO({ some block <eof>
- previously we'd never break lines when we discovered a structural
error; now we break even in the case of a structural error if there
are two unwrapped lines within the same line; thus,
void f() { while (true) { g(); y(); } }
will still be re-formatted, even if there's missing braces somewhere
in the file
- still exclude macro definitions from generating structural error;
macro definitions are inbalanced snippets
llvm-svn: 179379
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function declarations are now broken with the following preferences:
1) break amongst arguments.
2) break after return type.
3) break after (.
4) break before after nested name specifiers.
Options #2 or #3 are preferred over #1 only if a substantial number of
lines can be saved by that.
llvm-svn: 179287
|