C++98/03 and C++0x, since the '0x semantics break valid C++98/03
code. This new mess is tracked by core issue 399, which is still
unresolved.

Fixes PR6358 and PR6359.

llvm-svn: 96836

llvm-svn: 96819

itself rewritten. Radar 7669784.

llvm-svn: 96798

declaration. This is the trivial part of PR6365.

llvm-svn: 96792

llvm-svn: 96788

between cv1 T* and cv2 T*.

llvm-svn: 96787

CLANG_VTABLE_DEBUG.

llvm-svn: 96785

since they may not have normal identifiers for names. Fixes PR6369.

llvm-svn: 96784

not be guaranteed.

llvm-svn: 96782

llvm-svn: 96772

errors, e.g.:

t.c:1:21: error: redefinition of parameter 'x'
int test(int x, int x);
                    ^
t.c:1:14: note: previous declaration is here
int test(int x, int x);
             ^

llvm-svn: 96769

fixing up a few callers that thought they were propagating NoReturn
information but were in fact saying something about exception
specifications.

llvm-svn: 96766

  typedef int Int;
  int *p;
  p->Int::~Int();

This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.

llvm-svn: 96743

A constructor template cannot be used to copy to an object of the same class type (per C++ [class.copy]p3). Make sure that includes copies that involve a derived-to-base conversion. Fixes PR6141.

llvm-svn: 96742

Implement AST import for C++ member functions, including constructors, destructors, and conversions. Unfortunately, this cannot be tested yet, since we don't have C++ PCH support.

llvm-svn: 96741

llvm-svn: 96740

Collect the code that imports all of the members of a declaration context into a single function, ImportDeclContext. Use it rather than explicit loops. No functionality change.

llvm-svn: 96739

llvm-svn: 96738

figure out how not to break lots of code using this. See PR6358 and PR6359 for
motivating examples. FIXME's left in the code and the test.

llvm-svn: 96733

are for out of line declarations more easily. This simplifies the logic and
handles the case of out-of-line class definitions correctly. Fixes PR6107.

llvm-svn: 96729

instead it crashes on them.  We might extend this attribute to work on methods, but for
now fix the crasher.  Addresses <rdar://problem/7670939>.

llvm-svn: 96723

when -fms-extensions is specified.  Fixes <rdar://problem/7653870>.

llvm-svn: 96722

-fms-extensions is enabled.  Fixes <rdar://problem/7669559>.

llvm-svn: 96721

blocks. WIP.

llvm-svn: 96696

llvm-svn: 96695

there is a setter but no getter (part of radar 7664555).

llvm-svn: 96687

mode. This allows us to detect invalid VLAs in Objective-C++
mode. This should be the last of <rdar://problem/7660386>.

llvm-svn: 96679

from an instance method. Previously, we were following the Objective-C
name lookup rules for ivars, which are of course completely different
from and incompatible with the Objective-C++ rules.

For the record, the Objective-C++ rules are the sane ones.

This is another part of <rdar://problem/7660386>.

llvm-svn: 96677

name finds something other than a TypedefDecl or an
ObjCInterfaceDecl. This is a small part of <rdar://problem/7660386>.

llvm-svn: 96676

Fix some bugs with function-try-blocks and simplify normal try-block
code generation.

This implementation excludes a deleting destructor's call to
operator delete() from the function-try-block, which I believe
is correct but which I can't find straightforward support for at
a moment's glance.

llvm-svn: 96670

llvm-svn: 96660

The linker bug holding this back is Darwin-specific.

llvm-svn: 96655

This was causing buildbot breakage.

This reverts commit d46e952cc8cb8d9eed8657d9a0b267910a0f745a.

llvm-svn: 96652

llvm-svn: 96650

command-line option which defaults off.

llvm-svn: 96649

llvm-svn: 96648

llvm-svn: 96647

llvm-svn: 96646

operators, and compound assignment operators.

llvm-svn: 96643

to initializer expressions in an array allocated using ASTContext.

This plugs a memory leak when ASTContext uses a BumpPtrAllocator to
allocate memory for AST nodes.

In my mind this isn't an ideal solution; it would be nice to have
a general "vector"-like class that allocates memory using ASTContext,
but whose guts could be separated from the methods of InitListExpr
itself.  I haven't gone and taken this approach yet because it isn't
clear yet if we'll eventually want an alternate solution for recylcing
memory using by InitListExprs as we are constructing the ASTs.

llvm-svn: 96642