This results in libclang ignoring such methods.

llvm-svn: 137852

messages. Fi from David Blaikie, tests from Nikola Smiljanic!

llvm-svn: 137851

llvm-svn: 137849

automatically invoking llvm-gcc's cc1plus, which doesn't support all options
supported by Clang.  Therefore, filter out unsupported options.
rdar://9964354

llvm-svn: 137842

llvm-svn: 137839

llvm-svn: 137834

even when overloaded and user-defined. These operators are both more
valuable to warn on (due to likely typos) and extremely unlikely to be
reasonable for use to trigger side-effects.

llvm-svn: 137823

-Wunused was a mistake. It resulted in duplicate warnings and lots of
other hacks. Instead, this should be a special sub-category to
-Wunused-value, much like -Wunused-result is.

Moved to -Wunused-comparison, moved the implementation to piggy back on
the -Wunused-value implementation instead of rolling its own, different
mechanism for catching all of the "interesting" statements.

I like the unused-value mechanism for this better, but its currently
missing several top-level statements. For now, I've FIXME-ed out those
test cases. I'll enhance the generic infrastructure to catch these
statements in a subsequent patch.

This patch also removes the cast-to-void fixit hint. This hint isn't
available on any of the other -Wunused-value diagnostics, and if we want
it to be, we should add it generically rather than in one specific case.

llvm-svn: 137822

code is very likely to be buggy, but its going to require more
significant changes on the part of the user to correct it in this case.

llvm-svn: 137820

a complement to the warnings we provide in condition expressions. Much
like we warn on conditions such as:

  int x, y;
  ...
  if (x = y) ... // Almost always a typo of '=='

This warning applies the complementary logic to "top-level" statements,
or statements whose value is not consumed or used in some way:

  int x, y;
  ...
  x == y; // Almost always a type for '='

We also mirror the '!=' vs. '|=' logic.

The warning is designed to fire even for overloaded operators for two reasons:

1) Especially in the presence of widespread templates that assume
   operator== and operator!= perform the expected comparison operations,
   it seems unreasonable to suppress warnings on the offchance that
   a user has written a class that abuses these operators, embedding
   side-effects or other magic within them.
2) There is a trivial source modification to silence the warning for
   truly exceptional cases:

     (void)(x == y); // No warning

A (greatly reduced) form of this warning has already caught a number of
bugs in our codebase, so there is precedent for it actually firing. That
said, its currently off by default, but enabled under -Wall.

There are several fixmes left here that I'm working on in follow-up
patches, including de-duplicating warnings from -Wunused, sharing code
with -Wunused's implementation (and creating a nice place to hook
diagnostics on "top-level" statements), and handling cases where a proxy
object with a bool conversion is returned, hiding the operation in the
cleanup AST nodes.

Suggestions for any of this code more than welcome. Also, I'd really
love suggestions for better naming than "top-level".

llvm-svn: 137819

llvm-svn: 137814

llvm-svn: 137813

This is ugly but ISO C++ doesn't allow direct casts.

llvm-svn: 137812

[MSVC] Fix a warning C4334 "'operator' : result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)".

llvm-svn: 137803

llvm-svn: 137802

llvm-svn: 137799

llvm-svn: 137795

If we pass it a source location that points inside a function macro argument,
the returned location will be the macro location in which the argument was expanded.
If a macro argument is used multiple times, the expanded location will
be at the first expansion of the argument.
 e.g.
   MY_MACRO(foo);
             ^
Passing a file location pointing at 'foo', will yield a macro location
where 'foo' was expanded into.

Make SourceManager::getLocation call getMacroArgExpandedLocation as well.

llvm-svn: 137794

llvm-svn: 137793

[PCH] When writing out ExpansionInfo, make sure we don't lose track if it's a macro arg expansion or not.

llvm-svn: 137792

llvm-svn: 137780

[analyzer] teach ExprEngine about loads from static C++ class fields.  Fixes <rdar://problem/9948787>.

llvm-svn: 137760

[analyzer] Overhaul of checker registration in preparation for basic plugin support. Removes support for checker groups (we can add them back in later if we decide they are still useful), and -analyzer-checker-help output is a little worse for the time being (no packages).

llvm-svn: 137758

llvm-svn: 137750

llvm-svn: 137740

llvm-svn: 137720

[analyzer] Enhance ConditionVisitor to handle arbitrary ValueDecls in binary expressions, and also handle inverting the order of comparison when the named decl appears on the RHS.

llvm-svn: 137714

llvm-svn: 137708

[analyzer] Enhance ConditionVisitor to understand eagerly evaluated (simple) binary conditions, and teach it to only focus on constraint changes.

llvm-svn: 137705

[analyzer] add ExprEngine::getEagerlyAssumedTags() to allow externally querying of "eagerly assumed" expressions.

llvm-svn: 137704

llvm-svn: 137697

MacOSKeychainAPIChecker: The security API/memory leak checker should always generate regular nodes instead of sink nodes.

llvm-svn: 137681

llvm-svn: 137677

llvm-svn: 137674

test over from llvm/test/FrontendC++ and update others to account for
the change.

llvm-svn: 137669

llvm-svn: 137665

llvm-svn: 137653

Outside the driver, they were already treated that way, but the driver was not
giving them the same special treatment as -fapple-kext, e.g., falling back to
llvm-gcc for i386/Darwin kexts.  Radar 9868422.

llvm-svn: 137639

llvm-svn: 137638

MacOSKeychainAPIChecker: Use llvm::SmallString instead of std::string (as per code review for r137523).

llvm-svn: 137633