llvm-svn: 151586

depth and error if we exceed a max value, to make sure we avoid a stack overflow.

This is a hacky temporary fix. rdar://10913206.

llvm-svn: 151585

After numerous requests, have Objective-C 'method declared here' notes mention the actual method.  This looks better within an IDE, where text isn't always regurgitated in the presentation of a warning.  Fixes radar 10914035.

llvm-svn: 151579

llvm-svn: 151577

As in http://llvm.org/docs/ProgrammersManual.html#Statistic

llvm-svn: 151570

Fix a couple bugs in the way we handle array indexes in array bounds checking.  Specifically, make sure we don't ignore explicit casts in indexes, and make sure we use unsigned extension/comparisons on indexes.  Fixes <rdar://problem/10916006>.

llvm-svn: 151569

to make it more widely available.

Depends on llvm commit r151564

llvm-svn: 151566

Convert initializer lists to temporaries in CreateBuiltinBinOp. Allows assignment of init lists to built-in types and resolves PR12088.

llvm-svn: 151551

llvm-svn: 151549

llvm-svn: 151548

Found by valgrind.

llvm-svn: 151527

Fixes rdar://10934887

llvm-svn: 151519

default constructor of a union if it has a const member with no user-provided
default constructor.

llvm-svn: 151516

decltype expression.

llvm-svn: 151515

If the assignment operator is a scalar type, we continue to incorrectly reject
the initializer, but semantic analysis (and codegen) is correct for overloaded
operators.

llvm-svn: 151508

There's more potential here, but these Exprs aren't used that often so I don't feel like doing heroic bit packing right now.

-8 bytes on every class changed (x86_64).

llvm-svn: 151501

Move FullSourceLoc::dump into the .cpp file, the used attribute made us emit this into every TU that includes SourceLocation.h.

llvm-svn: 151493

non-trivial.

llvm-svn: 151486

Debian multiarch libraries, this should in theory add support for those
platform's header search rules. I don't have a system to check this
with, so review appreciated. I've added the corresponding tests
referring to the debian multiarch tree.

We are starting to have a relatively completely tested Linux platform
for header search and library search, with several interesting
peculiarities. We should point people at the debian_multiarch_tree when
suggesting new tests. Folks with Debian systems that can check this for
correctness, it would be much appreciated. The missing chunks I know of
are testing bi-arch peudo-cross-compiling toolchains betwen 32-bit and
64-bit variants of platforms, and the MIPS and ARM Debian toolchains.

llvm-svn: 151484

 - variant members with nontrivial destructors make the containing class's
   destructor deleted
 - check for a virtual destructor after checking for overridden methods in the
   base class(es)
 - check for an inaccessible operator delete for a class with a virtual
   destructor.

Do not try to call an anonymous union field's destructor from the destructor of
the containing class.

llvm-svn: 151483

Patch from Michel Dänzer, sent our way via Jeremy Huddleston who added
64-bit support. I just added one other place where powerpc64-linux-gnu
was missing (we only had powerpc64-unknown-linux-gnu).

I've also added a tree to test out the debian multiarch stuff. I don't
use debian regularly, so I'm not certain this is entirely accurate. If
anyone wants to check it against a debian system and fix any
inaccuracies, fire away. This way at least folks can see how this is
*supposed* to be tested.

It'd be particularly good to get the Debian MIPS toolchains tested in
this way.

llvm-svn: 151482

llvm-svn: 151478

trivial if the implicit declaration would be. Don't forget to set the Trivial
flag on the special member as well as on the class. It doesn't seem ideal that
we have two separate mechanisms for storing this information, but this patch
does not attempt to address that.

This leaves us in an interesting position where the has_trivial_X trait for a
class says 'yes' for a deleted but trivial X, but is_trivially_Xable says 'no'.
This seems to be what the standard requires.

llvm-svn: 151465

Original log:
When evaluating integer expressions handle logical operators outside
VisitBinaryOperator() to reduce stack pressure for source with huge number
of logical operators.

Fixes rdar://10913206.

llvm-svn: 151464

llvm-svn: 151462

VisitBinaryOperator() to reduce stack pressure for source with huge number
of logical operators.

Fixes rdar://10913206.

llvm-svn: 151460

llvm-svn: 151458

This emits a backing array with internal linkage and fills it with data,
then has the initializer_list point at the array. Dynamic initialization
and global destructors are correctly supported.

What doesn't work is nested initializer_lists. I have no idea how to
get them to work, either. However, these should be very rare, and so
I'll just call it a known bug and declare generalized initializers
DONE!

llvm-svn: 151457

llvm-svn: 151456

Better mangling for new-expressions. Also, although we can't mangle arbitrary initializer lists yet (we will need this), turn the crash into a controlled error.

llvm-svn: 151455

ARM: enable the integrated assembler by default for Darwin. 

llvm-svn: 151454

llvm-svn: 151447

likewise for __has_extension). Patch by Jonathan Sauer!

llvm-svn: 151445

in cases where we would otherwise disallow the access, and add a -Wc++98-compat
diagnostic for this C++11 feature.

llvm-svn: 151444

unevaluated operands applies within member functions, too.

llvm-svn: 151443

llvm-svn: 151442

data members for deleted or user-provided destructors.

Now it's computed in advance, serialize it, and in passing fix all the other
record DefinitionData flags whose serialization was missing.

llvm-svn: 151441

associated classes, since it can find friend functions declared within them,
but overload resolution does not otherwise require argument types to be
complete.

llvm-svn: 151434

rdar://10921594

llvm-svn: 151430

Work-in-progress for lambda conversion-to-block operator.  Still need to implement the retain+autorelease outside of ARC, and there's a bug that causes the generated code to crash in ARC (which I think is unrelated to my code, although I'm not completely sure).

llvm-svn: 151428