Rewriting the same predicates over and over again is bad for code size and
code maintainence. Using the functions in <ctype.h> is generally unsafe
unless they are specified to be locale-independent (i.e. only isdigit and
isxdigit).
The next commit will try to clean up uses of <ctype.h> functions within Clang.
llvm-svn: 174765
With this patch, the formatter introduces 'fake' parenthesis according
to the operator precedence of binary operators.
Before:
return aaaa & AAAAAAAAAAAAAAAAAAAAAAAAAAAAA || bbbb &
BBBBBBBBBBBBBBBBBBBBBBBBBBBBB || cccc & CCCCCCCCCCCCCCCCCCCCCCCCCC ||
dddd & DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD;
f(aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa &&
aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa);
After:
return aaaa & AAAAAAAAAAAAAAAAAAAAAAAAAAAAA ||
bbbb & BBBBBBBBBBBBBBBBBBBBBBBBBBBBB ||
cccc & CCCCCCCCCCCCCCCCCCCCCCCCCC ||
dddd & DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD;
f(aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa);
Future improvements:
- Get rid of some of the hacky ways to nicely format certain constructs.
- Merge this parser and the AnnotatingParser as we now have several parsers
that analyze (), [], etc.
llvm-svn: 174714
This is a powerful tool when doing iterative refined matches,
where another match is started inside the match callback of the first
one; this allows for example to find out whether the node was in
the condition or body of its parent if-statement.
llvm-svn: 174605
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
With this patch, clang-format can analyze the input file for two
properties:
1. Is "int *a" or "int* a" more common.
2. Are non-C++03 constructs used, e.g. A<A<A>>.
With Google-style, clang-format will now use the more common style for
(1) and format C++03 compatible, unless it finds C++11 constructs in the
input.
llvm-svn: 174504
A very common use case is to search for the first occurrence of
a certain node that is a descendant of another node. In that
case, selectFirst significantly simplifies the code at the client side.
llvm-svn: 174499
Properly handle annotation contexts while calculating extra information
for each token. This enable nested ObjC calls and thus solves (most of)
llvm.org/PR15164. E.g., we can now format:
[contentsContainer replaceSubview:[subviews objectAtIndex:0]
with:contentsNativeView];
Also fix a problem with the formatting of types in casts as this was
trivial now.
llvm-svn: 174498
1. let determineStarAmp() check of unary operators before checking for
"is next '['". That check was added in r173150, and the test from that
revision passes either way.
2. change determineStarAmp() to categorize '*' and '&' after '=' as unary
operator.
3. don't let parseSquare() overwrite the type of a '*' or '&' before the start
of an objc message expression if has the role of unary operator.
llvm-svn: 174489
We can now format stuff like:
- (void)doSomethingWith:(GTMFoo *)theFoo
rect:(NSRect)theRect
interval:(float)theInterval {
[myObject doFooWith:arg1 //
name:arg2
error:arg3];
}
This seems to fix everything mentioned in llvm.org/PR14939.
llvm-svn: 174364
In preprocessor definitions, we would not parse all the tokens and thus
not annotate them anymore. This led to a wrong formatting of comments
in google style:
#endif // HEADER_GUARD -- requires two spaces
llvm-svn: 174361
We found that findAll has been implemented incorrectly multiple times
by various people using the matchers. To prevent further wasted
development effort, it makes sense to add it as convenience matcher
implemented as eachOf(m, forEachDescendant(m)).
This patch also updates the docs with the new matchers.
llvm-svn: 174320
eachOf gives closure on the forEach and forEachDescendant matchers.
Before, it was impossible to implement a findAll matcher, as matching
the node or any of its descendants was not expressible (since anyOf
only triggers the first match).
llvm-svn: 174315
If there are string literals on either side of a '<<', chances are
high that they represent logically separate concepts. Otherwise,
the author could just have just a single literal (possible split
over multiple lines).
So, we can now nicely format things like:
cout << "somepacket = {\n"
<< " val a = " << ValueA << "\n"
<< " val b = " << ValueB << "\n"
<< "}";
llvm-svn: 174310
This combines several changes:
* Calculation token type (e.g. for * and &) in the AnnotatingParser.
* Calculate the scope binding strength in the AnnotatingParser.
* Let <> and [] scopes bind stronger than () and {} scopes.
* Add minimal debugging output.
llvm-svn: 174307
First, this implements a match() method on MatchFinder; this allows us
to get rid of the findAll implementation, as findAll is really a special
case of recursive matchers on match.
Instead of findAll, provide a convenience function match() that lets
users iterate easily over the results instead of needing to implement
callbacks.
llvm-svn: 174172
1. Never avoid bin packing in static initializers as this can
lead to terrible results.
2. If an element has to be broken over multiple lines, break after
the following comma.
This should be a step forward, but there are still many cases
especially with nested static initializers that we handle badly.
More patches will follow.
llvm-svn: 174061
The style guide only forbids this for function declarations. So,
now
someFunction(
aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa, aaaaaaaaaaaa);
Is allowed in Chromium mode.
llvm-svn: 173806
Jordan Rose