class template specializations (when possible) and look into base
classes. Thanks to Eli for the test case!

FIXME -=1.

llvm-svn: 80302

endian hosts.  Fixes PR4792

llvm-svn: 80301

cause any regressions.

llvm-svn: 80277

llvm-svn: 80276

llvm-svn: 80275

llvm-svn: 80274

llvm-svn: 80273

llvm-svn: 80272

templates within class templates, producing a member function template
of a class template specialization. If you can parse that, I'm
sorry. Example:

  template<typename T>
  struct X {
    template<typename U> void f(T, U);
  };

When we instantiate X<int>, we now instantiate the declaration
X<int>::f, which looks like this:

  template<typename U> void X<int>::f(int, U);

The path this takes through
TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and
ugly, but I don't know how to improve it yet. I'm resting my hopes on
the multi-level substitution required to instantiate definitions of
nested templates, which may simplify this code as well.

More testing to come...

llvm-svn: 80252

When checking whether one declaration context encloses another, make sure to look at the primary contexts. Thanks to Eli for the test case

llvm-svn: 80212

llvm-svn: 80211

Add a BuildCXXTemporaryObjectExpr and use it so default arguments will be instantiated correctly for temporary object expressions.

llvm-svn: 80206

llvm-svn: 80189

llvm-svn: 80185

almost correct.  :-)

llvm-svn: 80181

name, e.g.,
  
  x->Base::f()

retain the qualifier (and its source range information) in a new
subclass of MemberExpr called CXXQualifiedMemberExpr. Provide
construction, transformation, profiling, printing, etc., for this new
expression type.

When a virtual function is called via a qualified name, don't emit a
virtual call. Instead, call that function directly. Mike, could you
add a CodeGen test for this, too?

llvm-svn: 80167

types or type-dependent expressions.

llvm-svn: 80143

but not yet necessarily perfectly consistent with gcc.  Also addressed
Doug and John's comments.

llvm-svn: 80137

Issue reported on cfe-dev.

Also fixed the code to use isConstant to determine whether to generate a 
constant global, to be consistent with CodeGenModule.  This probably 
needs to be refactored to deal with C++, though.

llvm-svn: 80131

llvm-svn: 80129

Make sure to compare primary declaration contexts when determining whether a declaration is in scope

llvm-svn: 80126

TypenameType if getTypeName is looking at a member of an unknown
specialization. This allows us to properly parse class templates that
derived from type that could only otherwise be described by a typename type, 
e.g.,

  template<class T> struct X {};
  template<typename T> struct Y : public X<T>::X { }; 

Fixes PR4381.

llvm-svn: 80123

conversions, from Sylvere Teissier!

llvm-svn: 80112

Bagnara with a fix from Enea Zaffanella!

llvm-svn: 80094

llvm-svn: 80066

necessarily perfectly consistent with gcc.

llvm-svn: 80064

qualified name does not actually refer into a class/class
template/class template partial specialization. 

Improve printing of nested-name-specifiers to eliminate redudant
qualifiers. Also, make it possible to output a nested-name-specifier
through a DiagnosticBuilder, although there are relatively few places
that will use this leeway.

llvm-svn: 80056

Fix regression in BasicStoreManager caused by implicitly casting loaded values and trying to load/store from arrays.  RegionStoreManager already properly handles these cases well; we just need to gracefully not handle this case in BasicStoreManager.  This fixes PR 4781.

llvm-svn: 80051

when using the non-fragile Objective-C ABI.  This fixes <rdar://problem/7168531>.

llvm-svn: 80047

Test out-of-line definition of a static data member of a member class of a nested class template. Phew

llvm-svn: 80046

llvm-svn: 80045

their members, including member class template, member function
templates, and member classes and functions of member templates.

To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,

  template<typename X> template<typename Y>
  X Outer<X>::Inner1<Y>::foo(Y) {
    return X();
  }

we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.

Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.

llvm-svn: 80044

implicit cast logic in RegionStoreManager to BasicStoreManager. This involved
moving CastRetriedVal from RegionStoreManager to StoreManager.

llvm-svn: 80026

accurately.  Prevents the assert from triggering incorrectly when friending 
functions first declared in extern "C" contexts.  Fixes bug 4757.

llvm-svn: 80016

the logic is there for out-of-line definitions with multiple levels of
nested templates, but this is still a work-in-progress: we're having
trouble determining when we should look into a dependent
nested-name-specifier. 

llvm-svn: 80003

Fixes pr4771.

llvm-svn: 79999

llvm-svn: 79998

llvm-svn: 79991

llvm-svn: 79989

llvm-svn: 79987