avoid including ADT/Triple.h in many places when the target specific bits are
moved.

llvm-svn: 147059

so translate the range to file locations.

llvm-svn: 147058

llvm-svn: 147057

token locations as coming before the closing ')' of a function macro expansion.

Include a unit test for SourceManager.

llvm-svn: 147056

redeclaration chains: only ever have the reader search for
redeclarations of the first (canonical) declaration, since we only
ever record redeclaration ranges for the that declaration. Searching
for redeclarations of non-canonical declarations will never find
anything, so it's a complete waste of time.

llvm-svn: 147055

llvm-svn: 147054

side when the target specific bits are moved to the Target directory.

llvm-svn: 147053

llvm-svn: 147049

llvm-svn: 147048

llvm-svn: 147047

Remove mode specific disassembler classes and just call X86GenericDisassembler constructor with appropriate argument in the creation functions. This removes a few tables that needed to be anchored.

llvm-svn: 147046

llvm-svn: 147045

call site of an intrinsic is also not an inline candidate. While here, make it
more obvious that this code ignores all intrinsics. Noticed by inspection!

llvm-svn: 147037

llvm-svn: 147036

constant expressions.

llvm-svn: 147035

actually know about the other OSes on X86-32 besides Linux...

llvm-svn: 147034

llvm-svn: 147033

llvm-svn: 147032

 - constexpr function template instantiations
 - variables of reference type
 - constexpr variables

llvm-svn: 147031

llvm-svn: 147030

with incomplete definition data were being converted.
Now Clang attempts to complete RecordDecls before
converting them, avoiding a nasty crash.

llvm-svn: 147029

llvm-svn: 147028

llvm-svn: 147027

Fix a case where Expr::isConstantInitializer would return true for an expression we can't support.  In a slightly amusing twist, the case in question was already in the clang regression tests marked as a valid construct.  <rdar://problem/10020074>

llvm-svn: 147026

llvm-svn: 147025

The patch and test case were originally written by Mans Rullgard.

llvm-svn: 147024

members of class templates so that their values can be used in ICEs. This
required reverting r105465, to get such instantiated members to be included in
serialized ASTs.

llvm-svn: 147023

case for DCLO and DCLZ.

llvm-svn: 147022

llvm-svn: 147021

on method declaration and definition if former is in
a system header. // rdar://10580333

llvm-svn: 147020

llvm-svn: 147019

llvm-svn: 147018

DSHD (Double Swap Halfwords within Doublewords). Add a pattern which replaces
64-bit bswap with a DSBH and DSHD pair.

llvm-svn: 147017

types that have been imported multiple times.

The discussion below uses this diagram:

ASTContext     A      B      C
Decl           Da     Db     Dc
ASTImporter    \-Iab-/\-Iac-/
               \-----Iac----/

When a Decl D is imported from ASTContext A to
ASTContext B, the ASTImporter Iab records the
pair <Da, Db> in a DenseMap.  That way, if Iab
ever encounters Da again (for example, as the
DeclContext for another Decl), it can use the
imported version.  This is not an optimization,
it is critical: if I import the field "st_dev"
as part of importing "struct stat," the field
must have DeclContext equal to the parent
structure or we end up with multiple different
Decls containing different parts of "struct
stat."  "struct stat" is imported once and
recorded in the DenseMap; then the ASTImporter
finds that same version when looking for the
DeclContext of "st_dev."

The bug arises when Db is imported into another
ASTContext C and ASTContext B goes away.  This
often occurs when LLDB produces result variables
for expressions.  Ibc is aware of the transport
of Db to Dc, but a brand new ASTImporter, Iac,
is responsible for completing Dc from its source
upon request.  That ASTImporter has no mappings,
so it will produce a clone of Dc when attempting
to import its children.  That means that type
completion operations on Dc will fail.

The solution is to create Iac as soon as Ibc
imports D from B to C, and inform Iac of the
mapping between Da and Dc.  This allows type
completion to happen correctly.

llvm-svn: 147016

instruction supported by mips32r2, and add a pattern which replaces bswap with
a ROTR and WSBH pair.
 
WSBW is removed since it is not an instruction the current architectures
support.

llvm-svn: 147015

llvm-svn: 147014

llvm-svn: 147013

llvm-svn: 147012

llvm-svn: 147011

the build bot in some cases.  The basic issue happens when a source module contains
both a "%foo" type and a "%foo.42" type.  It will see the later one, check to see if
the destination module contains a "%foo" type, and it will return true... because
both the source and destination modules are in the same LLVMContext.  We don't want
to map source types to other source types, so don't do the remapping if the mapped
type came from the source module.

Unfortunately, I've been unable to reduce a decent testcase for this, kc++ is 
pretty great that way.

llvm-svn: 147010