Changed several of the Cocoa formatters to match the output style that Xcode uses internally to provide summaries
This has been done for those summaries where the difference is only cosmetic (e.g. naming things as items instead of values, ...)
The LLDB output style has been preserved when it provides more information (e.g. telling the type as well as the value of an NSNumber)

Test cases have been updated to reflect the updated output style where necessary

llvm-svn: 152592

llvm-svn: 152591

offset accumulation to use a boring APInt instead of ConstantExprs.
I didn't go all the way to an 'int64_t' because I wanted APInt to handle
any magic required to properly wrap the arithmetic when the pointer
width is <64 bits. If there is a significant penalty from using APInt
here, first off WTF, and secondly let me know and I'll do the math by
hand.

I've left one layer still operating w/ ConstantExpr because it makes the
interface quite a bit simpler, and that one isn't iterative so has much
lower cost.

I suppose this may potentially speed up some strang compilation
situations, but I don't really expect much. It should have no functional
impact either way.

llvm-svn: 152590

FYI,

On VS10, %INCLUDE% contains;
(VS10)\VC\INCLUDE
(VS10)\VC\ATLMFC\INCLUDE
(SDK70A)\include

On VS11,
(VS11)\VC\INCLUDE
(VS11)\VC\ATLMFC\INCLUDE
(SDK80)\include\shared
(SDK80)\include\um
(SDK80)\include\winrt

FIXME: It may be enabled also on mingw.
llvm-svn: 152589

llvm-svn: 152588

llvm-svn: 152587

llvm-svn: 152586

llvm-svn: 152584

* s/AddDirectoryList/addDirectoryList/
* Move the call to ::getenv into the function.
* FileCheck-ize the testcase.

llvm-svn: 152583

Suggestion by Bill Wendling!

llvm-svn: 152582

llvm-svn: 152581

registers not both being 64-bit or both being 32-bit registers.

llvm-svn: 152580

llvm-svn: 152579

The LIBRARY_PATH environment variable should be honored by clang. Have the
driver pass the directories to the linker.
<rdar://problem/9743567> and PR10296.

llvm-svn: 152578

llvm-svn: 152577

llvm-svn: 152576

functions that includes an explicit template argument list, perform
an inner deduction against each of the function templates in that list
and, if successful, use the result of that deduction for the outer
template argument deduction. Fixes PR11713.

llvm-svn: 152575

Patch by John Spencer

llvm-svn: 152574

Make sure we treat variables captured by reference in lambda as modifiable lvalues.  Regression from r152491.  Fixes PR12248.

llvm-svn: 152573

--- Reverse-merging r152486 into '.':
U    lib/CodeGen/SjLjEHPrepare.cpp

llvm-svn: 152571

 std::string has a summary provider
 std::vector std::list and std::map have both a summary and a synthetic children provider
Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two
The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic)

The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because
 (a) we need different compiler flags for libc++ than for libstdcpp
 (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference

llvm-svn: 152570

SBProcess::PutSTDIN() was not working for a few builds on darwin when using debugserver. This is now fixed.

llvm-svn: 152569

llvm-svn: 152568

llvm-svn: 152567

serialized
-Don't add methods of invalid objc containers to the global method pool.
 This protects us from trying to serialize a method whose container was not
 serialized.

Part of rdar://11007039.

llvm-svn: 152566

llvm-svn: 152565

ObjCBoolLiterals (__objc_yes/__objc_no) behave like C++ booleans (true/false). They are NOT objects.

llvm-svn: 152564

will reside in .objc_ivar$B sections. // rdar://11023490

llvm-svn: 152563

llvm-svn: 152559

llvm-svn: 152557

candidate set for subsequent inlining, try to simplify the arguments to
the inner call site now that inlining has been performed.

The goal here is to propagate and fold constants through deeply nested
call chains. Without doing this, we loose the inliner bonus that should
be applied because the arguments don't match the exact pattern the cost
estimator uses.

Reviewed on IRC by Benjamin Kramer.

llvm-svn: 152556

Typically instcombine has handled this, but pointer differences show up
in several contexts where we would like to get constant folding, and
cannot afford to run instcombine. Specifically, I'm working on improving
the constant folding of arguments used in inline cost analysis with
instsimplify.

Doing this in instsimplify implies some algorithm changes. We have to
handle multiple layers of all-constant GEPs because instsimplify cannot
fold them into a single GEP the way instcombine can. Also, we're only
interested in all-constant GEPs. The result is that this doesn't really
replace the instcombine logic, it's just complimentary and focused on
constant folding.

Reviewed on IRC by Benjamin Kramer.

llvm-svn: 152555

llvm-svn: 152554

llvm-svn: 152553

llvm-svn: 152552

being defined here: [] () -> struct S {} does not define struct S.

In passing, implement DR1318 (syntactic disambiguation of 'final').

llvm-svn: 152551

defined here, but not semantically, so

  new struct S {};

is always ill-formed, even if there is a struct S in scope.

We also had a couple of bugs in ParseOptionalTypeSpecifier caused by it being
under-loved (due to it only being used in a few places) so merge it into
ParseDeclarationSpecifiers with a new DeclSpecContext. To avoid regressing, this
required improving ParseDeclarationSpecifiers' diagnostics in some cases. This
also required teaching ParseSpecifierQualifierList about constexpr... which
incidentally fixes an issue where we'd allow the constexpr specifier in other
bad places.

llvm-svn: 152549

<rdar://problem/11024696>

llvm-svn: 152548

llvm-svn: 152547

statically writter metadata.
// rdar://11023490

llvm-svn: 152546