Remove an optimization where we were changing an objc_autorelease into an objc_autoreleaseReturnValue.

The semantics of ARC implies that a pointer passed into an objc_autorelease
must live until some point (potentially down the stack) where an
autorelease pool is popped. On the other hand, an
objc_autoreleaseReturnValue just signifies that the object must live
until the end of the given function at least.

Thus objc_autorelease is stronger than objc_autoreleaseReturnValue in
terms of the semantics of ARC* implying that performing the given
strength reduction without any knowledge of how this relates to
the autorelease pool pop that is further up the stack violates the
semantics of ARC.

*Even though objc_autoreleaseReturnValue if you know that no RV
optimization will occur is more computationally expensive.

llvm-svn: 178612

expressions are integer.  It can also be ValueDecl expressions

Use the type information from the TemplateParameterList instead

Patch by Olivier Goffart!

llvm-svn: 178611

When support was added for declaration arguments, the case of variadic
declaration arguments was not supported.  This patch fixes that problem by
not crashing when certain ValueDecl's are null.

Patch by Olivier Goffart!

llvm-svn: 178610

Value depenedent expressions for default arguments cannot be evaluated.
Instead, use the desugared template type to get an argument expression that
can be used.  This is needed for both integer and declaration arguements.

Also, move this common code into a separate function.

Patch by Olivier Goffart!

llvm-svn: 178609

Symbol table function names should support lookups like symbols with debug info. 

To fix this I:
- Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in
- Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much
- Filter the results at a higher level
- Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name.

llvm-svn: 178608

llvm-svn: 178607

however, it doesn't do that unless we're optimizing. Change
that and haul out to a helper function. Also make this a driver
test appropriate rather than an assembly test.

llvm-svn: 178606

llvm-svn: 178605

llvm-svn: 178604

Doxygen treats "@command" the same as "\command" in a doc comment, so
whenever we talk about Objective-C things like "@interface" we have to
make sure to escape them.

Let's try to keep Clang -Wdocumentation-clean!

llvm-svn: 178603

- Find the correct region to represent the first array element when
  constructing a CXXConstructorCall.
- If the array is trivial, model the copy with a primitive load/store.
- Don't warn about the "uninitialized" subscript in the AST -- we don't use
  the helper variable that Sema provides.

<rdar://problem/13091608>

llvm-svn: 178602

Reimplemented the NSDictionary synthetic children provider for added performance.
Instead of generating pairs by running an expression, we now create a pair type using clang-level APIs and fill in a buffer with the pointers to key and value
This strategy takes the time required to dump a 10k items __NSDictionaryM from ~45s to <4s

llvm-svn: 178601

Looks like the gcc in http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32/ doesn't like "not external linkage":

/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h: In instantiation of 'const bool llvm::yaml::has_SequenceMethodTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::value':
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h:281:   instantiated from 'llvm::yaml::has_SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >'
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/utils/yaml2obj/yaml2obj.cpp:627:   instantiated from here
/Volumes/Macintosh_HD2/buildbots/clang-x86_64-darwin11-self-mingw32/llvm.src/include/llvm/Support/YAMLTraits.h:243: error: 'llvm::yaml::SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::size' is not a valid template argument for type 'size_t (*)(llvm::yaml::IO&, std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> >&)' because function 'static size_t llvm::yaml::SequenceTraits<std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> > >::size(llvm::yaml::IO&, std::vector<<unnamed>::COFFYAML::Relocation, std::allocator<<unnamed>::COFFYAML::Relocation> >&)' has not external linkage

llvm-svn: 178600

a normal cleanup when entering a @try or @synchronized to
ensure that we clean that up if an exception is triggered.

Apparently GCC did this, so it's hard to argue that we shouldn't
do at least as much.

rdar://12364847

llvm-svn: 178599

when getting the host processor information.

llvm-svn: 178598

<rdar://problem/13552724>

llvm-svn: 178597

<rdar://problem/13558979>

llvm-svn: 178596

llvm-svn: 178595

The generic structs and specializations will be refactored when obj2yaml is
changed to use yaml::IO.

llvm-svn: 178593

warning when doing a __bride cast in non-arc
mode (which has no retain count effect).
// rdar://13514210

llvm-svn: 178592

llvm-svn: 178591

llvm-svn: 178590

llvm-svn: 178589

This patch initializes t9 to the handler address, but only if the relocation
model is pic. This handles the case where handler to which eh.return jumps 
points to the start of the function.

Patch by Sasa Stankovic.

llvm-svn: 178588

This reverts commit r178497 since the backend has been fixed.

Also add a test to ensure that we're emitting template information for unions.

llvm-svn: 178587

llvm-svn: 178586

llvm-svn: 178585

This patch fixes the following two tests which have been failing on
llvm-mips-linux builder since r178403:

LLVM :: Analysis/Profiling/load-branch-weights-ifs.ll
LLVM :: Analysis/Profiling/load-branch-weights-loops.ll

llvm-svn: 178584

llvm/test/CodeGen/X86: Unmark them out of XFAIL:cygming, in atomic{32|64}.ll and handle-move.ll, corresponding to r178549.

This reverts r176808, r176798, and r177914.

llvm-svn: 178583

It it still possible to extract information from itineraries, for
example.

llvm-svn: 178582

llvm-svn: 178581

llvm-svn: 178580

The cmake script is failing to copy cxxabi.h to the right place because it was generating to destination path like so /include// and dstdir can legally be blank from my interpretation of the script, and this would then generate a path like libcxx/include// which is illegal.

llvm-svn: 178579

- make an overload of Launch() that takes an init list of const char* if all you need to tweak in the launch info are the command-line arguments
- make Run() return an int that you can use as an exit-code
- make dynamic values work properly when recursing in FetchVariables()
- make the po output more obvious in verbose mode

llvm-svn: 178578

Fixing a bug where LLDB was not handling correctly CFStrings that have an explicit length but no NULL terminator
The data formatter was showing garbled data as part of the summary
The fix is to explicitly figure out the explicit length if we need to (bitfields tell us when that is the case) and use that as a size delimiter

llvm-svn: 178577

implementation of std::is_polymorphic does this:

template <class _Tp> struct __is_polymorphic1 : public _Tp {};

... and that g++ rejects this if _Tp has an inaccessible virtual destructor
(because __is_polymorphic1<_Tp> would have a deleted virtual destructor
overriding _Tp's non-deleted destructor). Clang was failing to reject this;
I've fixed that in r178563, but that causes libc++'s corresponding test
case to fail with both clang and gcc when using the fallback
implementation. The fallback code also incorrectly rejects final types.

The attached patch fixes the fallback implementation of is_polymorphic; we
now use dynamic_cast's detection of polymorphic class types rather than
trying to determine if adding a virtual function makes the type larger:

  enable_if<sizeof((_Tp*)dynamic_cast<const volatile
void*>(declval<_Tp*>())) != 0, ...>

Two things of note here:
* the (_Tp*) cast is necessary to work around bugs in Clang and g++ where
we otherwise don't instantiate the dynamic_cast (filed as PR15656)
* the 'const volatile' is here to treat is_polymorphic<cv T> as true for a
polymorphic class type T -- my reading of the standard suggests this is
incorrect, but it matches our builtin __is_polymorphic and gcc

llvm-svn: 178576

For variable declarations initialized with new expressions, use 'auto' for the
type specifier.

The 'auto' replacement happens only when the type of the VarDecl exactly
matches the type of the initializer and the VarDecl is *not* CV-qualified. The
only case that is currently handled is if the pointer type of the VarDecl is
itself CV qualified.

Some improvements need to be made to Clang's TypeLoc information in order for
other CV qualifier cases to be successfully handled. See the new test suite
new_cv_failing.cpp for examples of usages that could be handled with such an
improvement.

Function pointers are, for now, not transformed until the identifier info can
be extracted.

Reviewer: klimek
llvm-svn: 178575

Don't crash when there is no register context for a thread with kernel debugging. The kernel debugging uses the OperatingSystemPlugin that may behave badly when trying to get thread state, so be prepared to have invalid register contexts in threads.

llvm-svn: 178574

when we changed "rb" to "rbreak".

<rdar://problem/13552724>

llvm-svn: 178573

llvm-svn: 178572