llvm-svn: 72134

llvm-svn: 72129

operator in C++, and verify that template instantiation for the
condition operator does the right thing.

llvm-svn: 72127

llvm-svn: 72126

llvm-svn: 72119

llvm-svn: 72111

llvm-svn: 72102

When assigning from an rvalue to a const reference, the implicit cast from T -> const T is not an lvalue cast.

llvm-svn: 72082

llvm-svn: 72081

easier than expected because of the limitation that subscript
operators must be member functions.

llvm-svn: 72076

can be processed. No change in functionality.

llvm-svn: 72066

llvm-svn: 72058

llvm-svn: 72048

statement was using an rvalue reference during the template
definition. However, template instantiations based on an lvalue
reference type are well-formed, so we delay checking of these property
until template instantiation time.

llvm-svn: 72041

checking when block is envoked. In progress.

llvm-svn: 72039

llvm-svn: 72035

kinds of statements (in the instantiation logic). No functionality
change, but now we'll get linker errors if we add a statement but
forget to introduce its instantiation logic.

llvm-svn: 72031

llvm-svn: 72027

llvm-svn: 72020

template, introduce that member function into the template
instantiation stack. Also, add diagnostics showing the member function
within the instantiation stack and clean up the qualified-name
printing so that we get something like:

  note: in instantiation of member function 'Switch1<int, 2, 2>::f'
  requested here

in the template instantiation backtrace.

llvm-svn: 72015

llvm-svn: 71990

llvm-svn: 71989

llvm-svn: 71988

llvm-svn: 71984

llvm-svn: 71983

llvm-svn: 71982

llvm-svn: 71979

llvm-svn: 71970

llvm-svn: 71969

correct.  No functionality change, as far as I know.

llvm-svn: 71965

This makes me think that we should make hasExternalStorage perform this check...

llvm-svn: 71962

llvm-svn: 71961

llvm-svn: 71956

Implement instantiation of a few boring, simple expressions. I don't think these are testable yet, though.

llvm-svn: 71953

alternatives, but please correct me if I'm wrong.

I eventually plan to assert in mergeTypes that we aren't in C++ mode 
because composite types are fundamentally not a part of C++. The 
remaining callers for code in the regression tests are 
Sema::WarnConflictingTypedMethods and CodeGenFunction::EmitFunctionProlog;
I'm not quite sure what the correct approach is for those callers.

llvm-svn: 71946

llvm-svn: 71942

types.

llvm-svn: 71941

This patch isn't quite ideal in that it eliminates the warning for 
constructs like "int a = {1};", where the braces are in fact redundant.  
However, that would have required a bunch of refactoring, and it's 
much less likely to cause confusion compared to redundant nested braces.

llvm-svn: 71939

llvm-svn: 71936

llvm-svn: 71930