llvm-svn: 137838

Silly mistake from r137777; restore significant isStructTy() checks.  While here, be a bit more defensive
with unknown instructions.

Fixes PR10687.

llvm-svn: 137836

Radar 9959402.

llvm-svn: 137835

llvm-svn: 137834

llvm-svn: 137833

llvm-svn: 137832

llvm-svn: 137831

Allow the MCDisassembler to return a "soft fail" status code, indicating an instruction that is disassemblable, but invalid.  Only used for ARM UNPREDICTABLE instructions at the moment.
Patch by James Molloy.

llvm-svn: 137830

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

match splats in the form (splat (scalar_to_vector (load ...))) whenever
the load can be folded. All the logic and instruction emission is
working but because of PR8156, there are no ways to match loads, cause
they can never be folded for splats. Thus, the tests are XFAILed, but
I've tested and exercised all the logic using a relaxed version for
checking the foldable loads, as if the bug was already fixed. This
should work out of the box once PR8156 gets fixed since MayFoldLoad will
work as expected.

llvm-svn: 137810

llvm-svn: 137809

llvm-svn: 137808

vinsertf128 $1 + vpermilps $0, remove the old code that used to first
do the splat in a 128-bit vector and then insert it into a larger one.
This is better because the handling code gets simpler and also makes a
better room for the upcoming vbroadcast!

llvm-svn: 137807

llvm-svn: 137806

llvm-svn: 137805

llvm-svn: 137804

[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

When defining a scripted command, it is possible to provide a docstring and that will be used as the help text for the command
 If no docstring is provided, a default help text is created
LLDB will refuse to create scripted commands if the scripting language is anything but Python
Some additional comments in AppleObjCRuntimeV2.cpp to describe the memory layout expected by the dynamic type lookup code

llvm-svn: 137801

(void)static_func; it is used as idiom in llvm source tree to suppress "Unused static function" warnings.

llvm-svn: 137800

llvm-svn: 137799

llvm-svn: 137798

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

Use DynamicLibrary instances as a way to get symbols from a specific library. Preparation for upcoming (preliminary) support for plugins for the static analyzer.

llvm-svn: 137791