llvm-svn: 151510

llvm-svn: 151509

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

llvm-svn: 151507

llvm-svn: 151506

llvm-svn: 151505

llvm-svn: 151504

llvm-svn: 151503

llvm-svn: 151502

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

Apply the inheritance-padding trick to FloatingLiteral.
Shrinks CharacterLiteral from 32 to 24 bytes and the other two from 40 to 32 bytes (x86_64).

llvm-svn: 151500

Inheritance allows us to use padding across classes.
40 -> 32 bytes on x86_64.

llvm-svn: 151499

48 -> 40 bytes on x86_64.

llvm-svn: 151498

56 -> 48 bytes on x86_64.

llvm-svn: 151497

48 -> 40 bytes on x86_64.

llvm-svn: 151496

40 -> 32 bytes on x86_64.

llvm-svn: 151495

llvm-svn: 151494

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

llvm-svn: 151493

vector::emplace_back was mistakenly requiring move assignable.  Fixed that and did a little drive-by optimization at the same time.  This fixes http://llvm.org/bugs/show_bug.cgi?id=12085.

llvm-svn: 151492

llvm-svn: 151491

Turns out this can be .exe or .EXE, depending on the build system.

llvm-svn: 151490

Patch by Joey Gouly.

llvm-svn: 151489

llvm-svn: 151488

llvm-svn: 151487

non-trivial.

llvm-svn: 151486

r151482 and r151484 to work. Sorry about the fallout...

llvm-svn: 151485

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

Thanks zygoloid.

llvm-svn: 151481

llvm-svn: 151480

Add a random .LL file generator to stress-test different llvm components.

llvm-svn: 151479

llvm-svn: 151478

generalized initializers is available.

llvm-svn: 151477

more of the local path, platform path, associated symbol file, UUID, arch,
object name and object offset. This allows many of the calls that were
GetSharedModule to reduce the number of arguments that were used in a call
to these functions. It also allows a module to be created with a ModuleSpec
which allows many things to be specified prior to any accessors being called
on the Module class itself. 

I was running into problems when adding support for "target symbol add"
where you can specify a stand alone debug info file after debugging has started
where I needed to specify the associated symbol file path and if I waited until
after construction, the wrong  symbol file had already been located. By using
the ModuleSpec it allows us to construct a module with as little or as much
information as needed and not have to change the parameter list.

llvm-svn: 151476

llvm-svn: 151475

build. Testcase is still reducing.

llvm-svn: 151474

llvm-svn: 151473

llvm-svn: 151472

llvm-svn: 151471