order of constructor arguments (all block API specific). This was exposed only in 
a large block literal expression in a large file where PtrSet container size 
execceded its limit and required reallocation.  Fixes radar 7638294

llvm-svn: 95936

variable type, we can (and should) still check for completeness of the
variable's type. Do so, to work around an assertion that shows up in
Boost's shared_ptr.

llvm-svn: 95934

Fix leak in CXXNewExpr where the SubExprs array would get allocated directly using 'new[]' instead of the allocator associated with ASTContext.

llvm-svn: 95933

Fix re-allocation in AttrWithString::ReplaceString() to use the allocator assosciated with ASTContext.

llvm-svn: 95931

Allocate the SubExprs array in ObjCMessageExpr using the allocator associated with ASTContext.  This fixes yet another leak (<rdar://problem/7639260>).

llvm-svn: 95930

llvm-svn: 95922

llvm-svn: 95911

llvm-svn: 95908

llvm-svn: 95906

incompatibility and show where the structural differences are. For
example:

struct1.c:36:8: warning: type 'struct S7' has incompatible definitions
in different translation units
struct S7 { int i : 8; unsigned j : 8; } x7;
       ^
struct1.c:36:33: note: bit-field 'j' with type 'unsigned int' and length 8 here
struct S7 { int i : 8; unsigned j : 8; } x7;
                                ^
struct2.c:33:33: note: bit-field 'j' with type 'unsigned int' and length 16 here
struct S7 { int i : 8; unsigned j : 16; } x7;
                                ^

There are a few changes to make this work:
  - ASTImporter now has only a single Diagnostic object, not multiple
  diagnostic objects. Otherwise, having a warning/error printed via
  one Diagnostic and its note printed on the other Diagnostic could
  cause the note to be suppressed.
  - Implemented import functionality for IntegerLiteral (along with
  general support for statements and expressions)

llvm-svn: 95900

More vtable layout dumper improvements. Handle destructors, dump the complete function type of the member functions (using PredefinedExpr::ComputeName.

llvm-svn: 95887

llvm-svn: 95876

llvm-svn: 95874

their spelling location.  This prevents warnings from being swallowed just
because the caret is on the first parenthesis in, say, NULL.

This is an experiment;  the risk is that there might be a substantial number
of system headers which #define symbols to expressions which inherently cause
warnings.  My theory is that that's rare enough that it can be worked
around case-by-case, and that producing useful warnings around NULL is worth 
it.  But I'm willing to accept that I might be empirically wrong.

llvm-svn: 95870

Enhance the printf format string checking when using the format
specifier flags ' ', '0', '+' with the 'p' or 's' conversions (since
they are nonsensical and undefined).  This is similar to GCC's
checking.

Also warning when a precision is used with the 'p' conversin
specifier, since it has no meaning.

llvm-svn: 95869

Right now, it's off by default but can be tested by passing -fdump-vtable-layouts to clang -cc1. This option will cause all vtables that will normally be emitted as part of codegen to also be dumped using the new layout code.

I've also added a very simple new vtable layout test case.

llvm-svn: 95865

array associated with NonNullAttr.  This fixes yet another leak when
ASTContext uses a BumpPtrAllocator.

Fixes: <rdar://problem/7637150>
llvm-svn: 95863

storing the set of StoredDeclsMaps in an internal vector of void*.
This isn't an ideal solution, but for the time being this fixes a
major memory leak with these DenseMaps not being freed.

Fixes: <rdar://problem/7634755>
llvm-svn: 95861

array allocated using the allocator in ASTContext.  This addresses
these strings getting leaked when using a BumpPtrAllocator (in
ASTContext).

Fixes: <rdar://problem/7636765>
llvm-svn: 95853

llvm-svn: 95849

llvm-svn: 95848

we would just leak them all over the place, with no clear ownership of
these objects at all.  AttributeList objects would get leaked on both
error and non-error paths.

Note: I introduced the usage of llvm::OwningPtr<AttributeList> to
manage these objects, which is particularly useful for methods with
multiple return sites.  In at least one method I used them even when
they weren't strictly necessary because it clarified the ownership
semantics and made the code easier to read.  Should the excessive
'take()' and 'reset()' calls become a performance issue we can always
re-evaluate.

Note+1: I believe I have not introduced any double-frees, but it would
be nice for someone to review this.

This fixes <rdar://problem/7635046>.

llvm-svn: 95847

template explicit specialization.  Complete an apparently stalled refactor
towards using CheckSpecializationInstantiationRedecl().

llvm-svn: 95845

llvm-svn: 95843

Decl subclasses. No functionality change.

llvm-svn: 95841

using property dot-syntax. Fixes radar 7628953.

llvm-svn: 95838

and CXXRecordDecl::getDefinition(); it's totally unnecessary. No
functionality change.

llvm-svn: 95836

Allocate 'ObjCMethodList' objects (owned by Sema) using Sema's BumpPtrAllocator.  Previously they were not getting freed.  Fixes <rdar://problem/7635663>.

llvm-svn: 95834

llvm-svn: 95833

a __weak block. Fixes radar 7628591.

llvm-svn: 95822

Thanks, Anton!

llvm-svn: 95821

attribute, so it uses Anton's new target-specific attribute support. It's
supposed to ensure that the stack is 16-byte aligned, but since necessary
support is lacking from LLVM, this is a no-op for now.

llvm-svn: 95820

llvm-svn: 95812

llvm-svn: 95805

Fixes radar 7630551

llvm-svn: 95796

translation units.

llvm-svn: 95794

in a declaration statement. Fixes radar 7628153.

llvm-svn: 95788

calls to the UnwindResumeOrRethrow function for C++/Obj-C exception handling,
for Darwin ARM.

llvm-svn: 95787

llvm-svn: 95786

llvm-svn: 95785