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

llvm-svn: 104578

IRgen/C++: When mark vtables used, make sure to still append to the VTableUse array if we promote a vtable from being just used to having its definition required. This ensures that we properly inform the consumer about whether the vtable is required or not, previously we could fail to do so when the vtable was in the VTableUses array before the decl which marked it as required.
 - I think this can be cleaned up, since this means we may notify the consumer about the vtable twice, but I didn't see an easy fix for this without more substantial refactoring.
 - Doug, please review!

llvm-svn: 104577

llvm-svn: 104576

there are already two spaces before the token where the : was expected,
put the : in between the spaces.  This means we get it right in both
of these cases:

t.c:2:17: error: expected ':'
  return a ? b  c;
                ^
               :
t.c:3:16: error: expected ':'
  return a ? b c;
               ^
               : 

In the later case, the diagnostic says to insert ": ", in the former
case it says to insert ":" between the spaces.  This fixes rdar://8007231

llvm-svn: 104569

llvm-svn: 104566

llvm-svn: 104562

major buckets to catch parser and sema issues, add inline asm
category, and make diag groups take precedence over the 
sweeping categories just added.

llvm-svn: 104561

dependent. Fixes <rdar://problem/8021385>.

llvm-svn: 104550

promotion. Fixes <rdar://problem/8020920>.

llvm-svn: 104545

fatal error: too many errors emitted, stopping now [-ferror-limit=]

Tell the user that this is controlled with -ferror-limit=, like above.

llvm-svn: 104528

pointer is copied into a block. Fixes radar 7924024.

llvm-svn: 104526

class declaration's @end is not followed by a new-line.
(radar 7946975).

llvm-svn: 104512

aren't dependent. Fixes <rdar://problem/8020206>.

llvm-svn: 104511

extension warning (which other compilers seem to use). Works around a
known bug in Xalan.

llvm-svn: 104509

conversion. Fixes PR7095.

llvm-svn: 104476

type. Fixes PR7051.

llvm-svn: 104475

llvm-svn: 104474

llvm-svn: 104473

This works around a crash where malloc reused the memory of an erased BB for a
new BB leaving old cleanup information pointing at the new block.

llvm-svn: 104472

VLA restrictions so that one can use VLAs in templates (even
accidentally), but not as part of a non-type template parameter (which
would be very bad).

llvm-svn: 104471

llvm-svn: 104470

storage, rather than an UnresolvedSet. 

llvm-svn: 104469

UnresolvedMemberExpr in their constructors, rather than adding them
after the fact. No functionality change.

llvm-svn: 104468

pointers in the ASTContext, so that the folding sets stored inside
them will be deallocated when the ASTContext is destroyed (under
-disable-free). <rdar://problem/7998824>.

llvm-svn: 104465

llvm-svn: 104464

so that it can be selectively enabled/disabled.

llvm-svn: 104462