declaration of that array in C++.

llvm-svn: 81309

templates, e.g.,
  
  x.template get<T>

We can now parse these, represent them within an UnresolvedMemberExpr
expression, then instantiate that expression node in simple cases.

This allows us to stumble through parsing LLVM's Casting.h.

llvm-svn: 81300

as __strong.

llvm-svn: 81283

 - -1 FIXME, and fixes 'clang -arch armv4t ...', for example.

llvm-svn: 81276

in assiging to c pointer types with a GC'able
attribute.

llvm-svn: 81244

else it will make tests run faster and make 4888 easier to diagnose.

llvm-svn: 81238

llvm-svn: 81237

llvm-svn: 81233

llvm-svn: 81225

 - We aren't going to fix these since they haven't caused problems in practice.

 - Similarly, don't forward -object to Darwin ld.

llvm-svn: 81224

Handle variadic constructors better. Share code between BuildCXXConstructExpr and BuildCXXTemporaryObjectExpr.

llvm-svn: 81181

llvm-svn: 81176

llvm-svn: 81151

llvm-svn: 81143

situations.

llvm-svn: 81129

      for (unsigned i = numargs; i < NumArgs; ++i)
        Args[0] = 0;

;)

llvm-svn: 81123

destroying the CXXConstructExpr.", this is causing test failures across the
board.

llvm-svn: 81100

llvm-svn: 81099

Initialize default CXXConstructExpr arguments to 0. Fixes a crash when destroying the CXXConstructExpr.

llvm-svn: 81096

llvm-svn: 81063

llvm-svn: 81062

templates. We now distinguish between an explicit instantiation
declaration and an explicit instantiation definition, and know not to
instantiate explicit instantiation declarations. Unfortunately, there
is some remaining confusion w.r.t. instantiation of out-of-line member
function definitions that causes trouble here.
 

llvm-svn: 81053

Now that parsing, semantic analysis, and (I think) code generation of
pseudo-destructor expressions and explicit destructor calls works,
update the example-dynarray.cpp test to destroy the objects it
allocates and update the test to actually compile + link.
The code seems correct, but the Clang-compiled version dies with a
malloc error. Time to debug!

llvm-svn: 81025

formed without a trailing '(', diagnose the error (these expressions
must be immediately called), emit a fix-it hint, and fix the code.

llvm-svn: 81015

llvm-svn: 81011

expressions, e.g.,

  p->~T()

when p is a pointer to a scalar type. 

We don't currently diagnose errors when pseudo-destructor expressions
are used in any way other than by forming a call.

llvm-svn: 81009

then drop it on the floor.

llvm-svn: 80989

The problem this change addresses is that we treat __is_pod and
__is_empty as keywords in C++, because they are built-in type traits
in GCC >= 4.3. However, GNU libstdc++ 4.2 (and possibly earlier
versions) define implementation-detail struct templates named __is_pod
and __is_empty. 

This commit solves the problem by recognizing

  struct __is_pod

and

  struct __is_empty

as special token sequences. When one of these token sequences is
encountered, the keyword (__is_pod or __is_empty) is implicitly
downgraded to an identifier so that parsing can continue. This is an
egregious hack, but it has the virtue of "just working" whether
someone is using libstdc++ 4.2 or not, without the need for special
flags.

llvm-svn: 80988

llvm-svn: 80977

base and data members when they are needed.

llvm-svn: 80967

If the alignment of the chosen field in a union is greater than the alignment of the union, we need to use a packed LLVM struct. Fixes <rdar://problem/7184250>.

llvm-svn: 80964

things, this means that we can properly cope with member access
expressions such as 

  t->operator T()

where T is a template parameter (or other dependent type).

llvm-svn: 80957

involve qualified names, e.g., x->Base::f. We now maintain enough
information in the AST to compare the results of the name lookup of
"Base" in the scope of the postfix-expression (determined at template
definition time) and in the type of the object expression.

llvm-svn: 80953

as referecned with location where they are used. Still
need to look at destructor aspects of them.

llvm-svn: 80950

reference/const data members when user has declared
the constructor. This necessitated some non-minor
refactoring.

llvm-svn: 80934

  t->Base::f

where t has a dependent type. We save the nested-name-specifier in the
CXXUnresolvedMemberExpr then, during instantiation, substitute into
the nested-name-specifier with the (transformed) object type of t, so
that we get name lookup into the type of the object expression.

Note that we do not yet retain information about name lookup into the
lexical scope of the member access expression, so several regression
tests are still disabled.

llvm-svn: 80925

1) Issue digsnostics in non-fragile ABI, when an expression
   evaluates to an interface type (except when it is used to
   access a non-fragile ivar).
2) Issue unsupported error in fragile ABI when an expression
   evaluates to an interface type (except when it is used to
   access a fragile ivar).

llvm-svn: 80860

with to properly support member access expressions in templates. This
test is XFAIL'd, because we get it completely wrong, but I've made the
minimal changes to the representation to at least avoid a crash.

llvm-svn: 80856

must be defined. Fixed pr4853.

llvm-svn: 80846

  x->Base::f

We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.

We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.

I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.

llvm-svn: 80843