with incomplete definition data were being converted.
Now Clang attempts to complete RecordDecls before
converting them, avoiding a nasty crash.
llvm-svn: 147029
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
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
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
type is a pointer to const. (radar://10595327)
The regions corresponding to the pointer and reference arguments to
a function get invalidated by the calls since a function call can
possibly modify the pointed to data. With this change, we are not going
to invalidate the data if the argument is a pointer to const. This
change makes the analyzer more optimistic in reporting errors.
(Support for C, C++ and Obj C)
llvm-svn: 147002
Use the spill slot alignment as well as the local variable alignment to
determine when the stack needs to be realigned. This works now that the
ARM target can always realign the stack by using a base pointer.
Still respect the ARMBaseRegisterInfo::canRealignStack() function
vetoing a realigned stack. Don't use aligned spill code in that case.
llvm-svn: 146997
Richard Smith