Before:
  x[(uint8) y];
  x = (uint8) y;
  void f() { x = (uint8) y; }
  #define AA(X) sizeof(((X *) NULL)->a)

After:
  x[(uint8)y];
  x = (uint8)y;
  void f() { x = (uint8)y; }
  #define AA(X) sizeof(((X *)NULL)->a)

llvm-svn: 183014

llvm-svn: 183010

If a "}" is found inside parenthesis, this is probably a case of
missing parenthesis. This enables continuing to format after stuff code
like:

class A {
  void f(
};
..

llvm-svn: 183009

With this patch, the simplified rule is:
If the block is part of a declaration (class, namespace, function,
enum, ..), merge an empty block onto a single line. Otherwise
(specifically for the compound statements of if, for, while, ...),
keep the braces on two separate lines.

The reasons are:
- Mostly the formatting of empty blocks does not matter much.
- Empty compound statements are really rare and are usually just
  inserted while still working on the code. If they are on two lines,
  inserting code is easier. Also, overlooking the "{}" of an
  "if (...) {}" can be really bad.
- Empty declarations are not uncommon, e.g. empty constructors. Putting
  them on one line saves vertical space at no loss of readability.

llvm-svn: 183008

Before:
bool aaaaaa = aaaaaaaaaaaaa //
                  ? aaaaaaaaaaaaaaa
                  : bbbbbbbbbbbbbbb //
                  ? ccccccccccccccc
                  : ddddddddddddddd;

After:
bool aaaaaa = aaaaaaaaaaaaa //
                  ? aaaaaaaaaaaaaaa
                  : bbbbbbbbbbbbbbb //
                        ? ccccccccccccccc
                        : ddddddddddddddd;

llvm-svn: 183007

Before:
foo = aaaaaaaaaaa ? vector<int> {
  aaaaaaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa, aaaaa
}
: vector<int>{ bbbbbbbbbbbbbbbbbbbbbbbbbbb, bbbbbbbbbbbbbbbbbbbb, bbbbb };

After:
foo = aaaaaaaaaaa ? vector<int>{ aaaaaaaaaaaaaaaaaaaaaaaaaaa,
                                 aaaaaaaaaaaaaaaaaaaa, aaaaa }
                  : vector<int>{ bbbbbbbbbbbbbbbbbbbbbbbbbbb,
                                 bbbbbbbbbbbbbbbbbbbb, bbbbb };

llvm-svn: 182992

[analyzer; new edges] in splitBranchConditionEdges() do not check that predecessor edge has source in the same lexical scope as the target branch.

Fixes <rdar://problem/14031292>.

llvm-svn: 182987

llvm-svn: 182986

initialization. Previously we would incorrectly require an extra set of braces
around such initializers.

llvm-svn: 182983

llvm-svn: 182982

The new advanced option ensures ccc-analyze is used even when better
interposition methods are available.

llvm-svn: 182981

In a certain code-path we were not deserializing an anonymous field initializer correctly,
leading to a crash when trying to IRGen it.

This is a simpler version of a patch by Yunzhong Gao!

llvm-svn: 182974

syntactic form in template instantiation. Previously, this blocked the
reversion and we ended up losing inner CXXBindTemporaryExprs (and thus
forgetting to call destructors!).

llvm-svn: 182969

llvm-svn: 182966

which diagnoses type mismatches of identical 
selectors declared in classes throughout.
// rdar://14007194

llvm-svn: 182964

...and make this work correctly in the current codebase.

After living on this for a while, it turns out to look very strange for
inlined functions that have only a single statement, and somewhat strange
for inlined functions in general (since they are still conceptually in the
middle of the path, and there is a function-entry path note).

It's worth noting that this only affects inlined functions; in the new
arrow generation algorithm, the top-level function still starts at the
first real statement in the function body, not the enclosing CompoundStmt.

This reverts r182078 / dbfa950abe0e55b173286a306ee620eff5f72ea.

llvm-svn: 182963

The testcase in PR16060 points out that while template arguments can
show that a type is not externally visible, the standards still says
they have external linkage.

In terms of our implementation, it means that we should merge just the
isExternallyVisible bit, not the formal linkage.

llvm-svn: 182962

Fix potential infinite loop when iterating over redeclarations of an ObjMethodDecl, resulting from invalid code.

Check for invalid decls in ObjCMethodDecl::getNextRedeclaration(); otherwise if we start from an invalid redeclaration
of an @implementation we would move to the @interface and not reach the original declaration again.

Fixes rdar://14024851

llvm-svn: 182951

It is okay to declare a block without an argument list: ^ {} or ^void {}.
In these cases, the BlockDecl's signature-as-written will just contain
the return type, rather than the entire function type. It is unclear if
this is intentional, but the analyzer shouldn't crash because of it.

<rdar://problem/14018351>

llvm-svn: 182948

Do not reuse the debug location of the return value's store if there is autorelease code to be emitted between store and return instructions. This is analoguous to what we do for lexical scope cleanups.

rdar://problem/13977888

llvm-svn: 182947

llvm-svn: 182946

llvm-svn: 182940

references.  What's more, they use this language extension in their
ATL header files (which come as part of MFC and the Win32 SDK).  This patch implements support for the Microsoft extension, and addresses PR13737.

llvm-svn: 182936

Found by -Wdocumentation.

llvm-svn: 182934

This fixes:
/*
*
* something long going over the column limit.
*/

llvm-svn: 182932

llvm-svn: 182930

llvm-svn: 182927

This way, it has the same default as 'patch' and also the example in the
code makes more sense as it is explicitly setting -p 1.

llvm-svn: 182923

llvm-svn: 182916

Smallest reproduction:
/*
**
*/

llvm-svn: 182913

llvm-svn: 182911

Switching the tests to use size_t instead of unsigned int to hopefully appease the Linux x64 build bot (take 2, forgot this test case).

llvm-svn: 182907

Switching the tests to use size_t instead of unsigned int to hopefully appease the Linux x64 build bot.

llvm-svn: 182906

Add support to fallback on operator new when a placement operator new[] is called for which there is no valid declaration.  This fallback only happens in Microsoft compatibility mode.  This patch addresses PR13164, and improves support for the WDK.

llvm-svn: 182905

Most loop notes (like "entering loop body") are attached to the condition
expression guarding a loop or its equivalent. For loops may not have a
condition expression, though. Rather than crashing, just use the entire
ForStmt as the location. This is probably the best we can do.

<rdar://problem/14016063>

llvm-svn: 182904

[libclang] When indexing a @synthesize, don't consider that it defines a getter/setter if one is already defined by the user.

Fixes rdar://13925258

llvm-svn: 182895

Document -fno-sanitize-recover and -fsanitize-undefined-trap-on-error and attempt to explain the difference between them.

llvm-svn: 182890

When trying to fall back to search from the end onwards, we
would still find leading whitespace if the leading whitespace
went on after the end of the line.

llvm-svn: 182886

This change is motivated from user feedback that some APIs use
void* as an opaque "context" object that may not really be a pointer.
Such users want an ability to turn off the warning for casts
to void* while preserving the warning for other cases.

Implements <rdar://problem/14016721>.

llvm-svn: 182884

llvm-svn: 182882