llvm-svn: 104714

llvm-svn: 104712

llvm-svn: 104702

llvm-svn: 104701

llvm-svn: 104700

llvm-svn: 104695

llvm-svn: 104693

any arguments that are default-argument expressions. The can show up
when we have a new expression whose constructor arguments are not
type-dependent and whose allocated type is not dependent and has a
constructor with default arguments. Fixes PR7202.

llvm-svn: 104690

llvm-svn: 104688

llvm-svn: 104687

llvm-svn: 104686

llvm-svn: 104685

diagnostics. That would be while we're parsing string literals for the
sole purpose of producing a diagnostic about them. Fixes
<rdar://problem/8026030>.

llvm-svn: 104684

llvm-svn: 104683

llvm-svn: 104682

llvm-svn: 104681

vtables, VTTs, and construction vtables. Fixes PR7201.

llvm-svn: 104675

llvm-svn: 104674

llvm-svn: 104673

Fold the ASTRecordLayoutBuilder::ComputeLayout overload that takes an ObjCInterfaceDecl pointer into its only callsite.

llvm-svn: 104672

Move the relevant ASTContext member functions that deal with ASTRecordLayoutBuilder into RecordLayoutBuilder.cpp. This matches the way we interact with other builder classes (CGRecordLayoutBuilder, VTableBuilder and VTTBuilder) and it also allows for making ASTRecordLayoutBuilder a private class without a header file.

llvm-svn: 104671

llvm-svn: 104669

This requires creating new persistent states due to the nature of GDM.

llvm-svn: 104668

statements }) in the code-completion results if explicitly requested.

llvm-svn: 104637

a massive memory leak when using a BumpPtrAllocator in ASTContext.

Added a FIXME, as the Destroy method for TemplateArgumentList isn't getting called.
This means we will instead leak when using the MallocAllocator.

llvm-svn: 104633

llvm-svn: 104631

This class only supports name mangling (which is apparently used during C/ObjC
codegen). For now only the Itanium C++ ABI is supported. Patches to add a
second C++ ABI are forthcoming.

llvm-svn: 104630

.s printer or .o writer.

llvm-svn: 104623

  (DeclStmt 0x3405550 <line:3:4, col:11>
    0x34053a0 "int x")
instead of:
  (DeclStmt 0x3405550 <line:3:4, col:11>
    0x34053a0 "int x"

which has unbalanced parens (PR7228)

llvm-svn: 104620

llvm-svn: 104618

llvm-svn: 104614

llvm-svn: 104613

variables within blocks. We loosely follow GCC's mangling, but since
these are always internal symbols the names don't really matter. I
intend to revisit block mangling later, because GCC's mangling is
rather verbose. <rdar://problem/8015719>.

llvm-svn: 104610

methods. (Radar 7987817).

llvm-svn: 104608

derived-to-base conversion on a pointer. Fixes PR7224.

llvm-svn: 104607

llvm-svn: 104606

llvm-svn: 104586

  1) Suppress diagnostics as soon as we form the code-completion
  token, so we don't get any error/warning spew from the early
  end-of-file.
  2) If we consume a code-completion token when we weren't expecting
  one, go into a code-completion recovery path that produces the best
  results it can based on the context that the parser is in.

llvm-svn: 104585

whether the size of the symbolic region is a multiple of the size of T.
Fixes PR6123 and PR7217.

llvm-svn: 104584

variables should have that linkage.  Otherwise, its static local
variables should have internal linkage.  To avoid computing this excessively,
set a function's linkage before we emit code for it.

Previously we were assigning weak linkage to the static variables of
static inline functions in C++, with predictably terrible results.  This
fixes that and also gives better linkage than 'weak' when merging is required.

llvm-svn: 104581