Allows formatting of C++11 braced init list constructs, like:
vector<int> v { 1, 2, 3 };
f({ 1, 2 });
This involves some changes of how tokens are handled in the
UnwrappedLineFormatter. Note that we have a plan to evolve the
design of the token flow into one where we create all tokens
up-front and then annotate them in the various layers (as we
currently already have to create all tokens at once anyway, the
current abstraction does not help). Thus, this introduces
FIXMEs towards that goal.
llvm-svn: 182568
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
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
Summary:
Some codebases use these kinds of macros in functions, e.g. Chromium's
IPC_BEGIN_MESSAGE_MAP, IPC_BEGIN_MESSAGE_HANDLER, etc.
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D645
llvm-svn: 179099
Summary:
It turns out that we don't need to store CommentsBeforeNextToken in the
line state, but rather flush them before we start parsing preprocessor
directives. This fixes wrong comment indentation in code blocks in macro calls
(the test is included).
Reviewers: klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D617
llvm-svn: 178638
Comments before preprocessor directives used to be stored with InPPDirective
flag set, which prevented correct comment splitting in this case. Fixed by
flushing comments before switching on InPPDirective. Added a new test and fixed
one of the existing tests.
llvm-svn: 178261
It turns out that
-foo;
can be an objective C method declaration. So instead of the previous
solution, recognize objective C methods only if we are in a declaration
scope.
llvm-svn: 177740
This seems to be generally more desired.
Before:
if (aaaaaaaa &&
bbbbbbbb >
cccccccc) {}
After:
if (aaaaaaaa &&
bbbbbbbb >
cccccccc) {}
Also: Some formatting cleanup on clang-format's files.
llvm-svn: 177514
Still the formatting can be improved, but at least we don't assert any
more. This happened when trying to format lib/Sema/SemaType.cpp.
llvm-svn: 175003
Before:
@{
foo:
bar
}
;
Now:
@{ foo : bar };
parseBracedList() already does the right thing from an UnwrappedLineParser
perspective, so check for "@{" in all loops that process constructs that can
contain expressions and call parseBracedList() if found.
llvm-svn: 174840
We now correctly format:
// Written as a macro, it is reformatted from:
#define foo(a) \
do { \
/* Initialize num to zero. */ \
int num = 10; \
/* This line ensures a is never zero. */ \
int i = a == 0 ? 1 : a; \
i = num / i; /* This division is OK. */ \
return i; \
} while (false)
llvm-svn: 174517
Layouting would prevent breaking before + in
a[b + c] = d;
Regression detected by code review.
Also fixes an invalid-read found by the valgrind bot.
llvm-svn: 173262
This gives us the ability to guess better defaults for whether a *
between identifiers is a pointer dereference or binary operator.
Now correctly formats:
void f(a *b);
void f() { f(a * b); }
llvm-svn: 173243
Changing nextToken() in the UnwrappedLineParser to get the next
non-comment token. This allows us to correctly layout a whole class of
snippets, like:
if /* */(/* */ a /* */) /* */
f() /* */; /* */
else /* */
g();
Fixes a bug in the formatter where we would assume there is a previous
non-comment token.
Also adds the indent level of an unwrapped line to the debug output in
the parser.
llvm-svn: 173168
Very similar to what we do for record definitions:
- tighten down what is an enum definition, so that we don't mistake a
function for an enum
- allow common idioms around declarations (we'll want to handle that
more centrally in the future)
We now correctly format:
enum X f() {
a();
return 42;
}
llvm-svn: 173075
We now only put empty blocks into a single line, if all of:
- all tokens of the structural element fit into a single line
- we're not in a control flow statement
Note that we usually don't put record definitions into a single line, as
there's usually at least one more token (the semicolon) after the
closing brace. This doesn't hold when we are in a context where there is
no semicolon, like "enum E {}".
There were some missing tests around joining lines around the corner
cases of the allowed number of columns, so this patch adds some.
llvm-svn: 173055
Previously, we would not detect brace initializer lists in return
statements, thus:
return (a)(b) { 1, 2, 3 };
would put the semicolon onto the next line.
llvm-svn: 173017
Manually fix the order of UnwrappedLineParser.cpp as that one didn't
have its associated header as the first header.
This also uncovered a subtle inclusion order dependency as CLog.h didn't
include LLVM.h to pick up using declarations it relied upon.
llvm-svn: 172892
This patch prepares being able to test for and fix more problems (see
FIXME in the test for example).
Previously we would output unwrapped lines for preprocessor directives
at the point where we also parsed the hash token. Since often
projections only terminate (and thus output their own unwrapped line)
after peeking at the next token, this would lead to the formatter seeing
the preprocessor directives out-of-order (slightly earlier). To be able
to correctly identify lines to merge, the formatter needs a well-defined
order of unwrapped lines, which this patch introduces.
llvm-svn: 172819
Leave a quick "// Uncomment this." hint to enable the debug output in
tests. FIXME: figure out whether we want to enable debug command line
handling for all tests.
llvm-svn: 172608
It was quite convoluted leading to us accidentally introducing O(N^2)
complexity while copying from UnwrappedLine to AnnotatedLine. We might
still want to improve the datastructure in AnnotatedLine (most
importantly not put them in a vector where they need to be copied on
vector resizing but that will be done as a follow-up.
This fixes most of the regression in llvm.org/PR14959.
No formatting changes intended.
llvm-svn: 172602
This switches to parsing record definitions only if we can clearly
identify them. We're specifically allowing common patterns for
visibility control through macros and attributes, but we cannot
currently fix all instances. This fixes all known bugs we have though.
Before:
static class A f() {
return g();
} int x;
After:
static class A f() {
return g();
}
int x;
llvm-svn: 172530
Note that I don't know whether we should put {} on a single line in this
case, but it is probably a theoretical issue as in practice such
structs, classes or unions won't be empty.
Before: union A {}
a;
After: union A {} a;
llvm-svn: 172355
Manuel Klimek