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

Patch by Anders Waldenborg!

llvm-svn: 137829

llvm-svn: 137828

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

llvm-svn: 137821

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: 137816

llvm-svn: 137814

llvm-svn: 137813

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

llvm-svn: 137812

llvm-svn: 137811

llvm-svn: 137805

[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

Patch by Anders Waldenborg!

llvm-svn: 137797

e.g. for:

\define INVOKE(METHOD, CLASS) [CLASS METHOD]

void test2() {
  INVOKE(meth, MyClass);
}

Pointing at 'meth' will give a CXCursor_ObjCMessageExpr and pointing at 'MyClass'
will give a CXCursor_ObjCClassRef.

llvm-svn: 137796

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

llvm-svn: 137773

llvm-svn: 137772

llvm-svn: 137771

llvm-svn: 137770

llvm-svn: 137769

llvm-svn: 137768

llvm-svn: 137767

llvm-svn: 137766

llvm-svn: 137765

llvm-svn: 137764

llvm-svn: 137763