The styles are now documented with the -style option. This fixes
llvm.org/PR15689.

llvm-svn: 179017

llvm-svn: 179016

llvm-svn: 179015

Fixes PR15693. A null check on a pointer returned from cast<> is a very dubious
construct, do we have a checker for this somewhere?

llvm-svn: 178975

llvm-svn: 178952

linkage specification, and is marked as __attribute__((used)), try to also give
it the unmangled name (by emitting an internal linkage alias) if nothing else
within the translation unit would use that name. This allows inline asm in that
translation unit to use the entity via its unmangled name, which people
apparently rely on.

llvm-svn: 178950

This is important because sometimes two nodes are identical, except the
second one is a sink.

This bug has probably been around for a while, but it wouldn't have been an
issue in the old report graph algorithm. I'm ashamed to say I actually looked
at this the first time around and thought it would never be a problem...and
then didn't include an assertion to back that up.

PR15684

llvm-svn: 178944

rdar://13181413

llvm-svn: 178942

<rdar://problem/13325066> Destroy std::initializer_list temporaries whose lifetime has been extended by reference binding.

llvm-svn: 178939

As per Ted’s suggestion!

llvm-svn: 178938

New rule:
- Method decls in @implementation are considered "redeclarations"
  and inherit deprecated/availability from the @interface.
- All other cases are consider overrides, which do not inherit
  deprecated/availability.  For example:

  (a) @interface redeclares a method in an adopted protocol.
  (b) A subclass redeclares a method in a superclass.
  (c) A protocol redeclares a method from another protocol it adopts.

The idea is that API authors should have the ability to easily
move availability/deprecated up and down a class/protocol hierarchy.
A redeclaration means that the availability/deprecation is a blank
slate.

Fixes <rdar://problem/13574571>

llvm-svn: 178937

llvm-svn: 178935

llvm-svn: 178934

[analyzer] Fix null tracking for the given test case, by using the proper state and removing redundant code.

llvm-svn: 178933

more information to the notes.  This information is already present on other
diagnostic messages that involves overloads.

llvm-svn: 178923

rdar://13535645

llvm-svn: 178911

llvm-svn: 178906

// rdar://12379114

llvm-svn: 178903

Now treat AF_None family as impossible in isTrackedFamily()

llvm-svn: 178899

llvm-svn: 178898

As mentioned in the previous commit message, the use-after-free and
double-free warnings for 'delete' are worth enabling even while the
leak warnings still have false positives.

llvm-svn: 178891

This splits the leak-checking part of alpha.cplusplus.NewDelete into a
separate user-level checker, alpha.cplusplus.NewDeleteLeaks. All the
difficult false positives we've seen with the new/delete checker have been
spurious leak warnings; the use-after-free warnings and mismatched
deallocator warnings, while rare, have always been valid.

<rdar://problem/6194569>

llvm-svn: 178890

(Don't ask, this was a user request).

llvm-svn: 178888

Before:
bool operator<
    (const aaaaaaaaaaaaaaaaaaaaa &left, const aaaaaaaaaaaaaaaaaaaaa &right) {
  return left.group < right.group;
}

After:
bool operator<(const aaaaaaaaaaaaaaaaaaaaa &left,
               const aaaaaaaaaaaaaaaaaaaaa &right) {
  return left.group < right.group;
}

llvm-svn: 178887

llvm-svn: 178886

llvm-svn: 178882

llvm-svn: 178878

The prefixes and names used are now identical to 32-bit ARM, which is also
expected to remain unchanged.

If we made this change after a release, we'd probably have to support both
variants for a while, but I think since AArch64 exists only on trunk now, it's
acceptable to simply swap them now.

llvm-svn: 178870

llvm-svn: 178862

llvm-svn: 178861

This fixed llvm.org/PR15670

Before:
aaaaaaaaa a = aaaaaaaaaaaaaaaaaaaa, b = bbbbbbbbbbbbbbbbbbbb,
                                    c = cccccccccccccccccccc,
                                    d = dddddddddddddddddddd;
aaaaaaaaa *a = aaaaaaaaaaaaaaaaaaa, *b = bbbbbbbbbbbbbbbbbbb,
                                     *c = ccccccccccccccccccc,
                                      *d = ddddddddddddddddddd;

After:
aaaaaaaaa a = aaaaaaaaaaaaaaaaaaaa, b = bbbbbbbbbbbbbbbbbbbb,
          c = cccccccccccccccccccc, d = dddddddddddddddddddd;
aaaaaaaaa *a = aaaaaaaaaaaaaaaaaaa, *b = bbbbbbbbbbbbbbbbbbb,
          *c = ccccccccccccccccccc, *d = ddddddddddddddddddd;

llvm-svn: 178860

Allow EmitConstantInit() to emit constant initializers for objects with trivial constructors and non-trivial destructors. Test that such objects are ignored by init-order checker.

llvm-svn: 178856

The statement passed to isTrackedFamily() might be a user defined function calling malloc; in this case we got AF_NONE family for this function.
Now the allocation family is derived from Sym, that holds a family of a real allocator.

This commit is also a movement towards getting rid of tracking memory allocating by unknown means.

llvm-svn: 178834

llvm-svn: 178831

Also had to modify the PostInitializer ProgramLocation to contain the field region.

llvm-svn: 178826

Thanks a lot to Richard Smith for the suggestion.

llvm-svn: 178825

Missed check added to testMallocFreeNoWarn().
Removed FIXMEs as the current behaviour is considered acceptable now.

llvm-svn: 178824

llvm-svn: 178820

llvm-svn: 178818

This fixes std::thread with libstdc++.

llvm-svn: 178816