disable this feature for now, to err on the side of rejecting instead
of sometimes crashing.  rdar://6326239

llvm-svn: 68088

within nested-name-specifiers, e.g., for the "apply" in

  typename MetaFun::template apply<T1, T2>::type

At present, we can't instantiate these nested-name-specifiers, so our
testing is sketchy.

llvm-svn: 68081

llvm-svn: 68077

representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").

One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as

  std::(vector<int>)

we represent it as

  (std::vector)<int>

which more closely follows the C++ grammar. 

Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.

llvm-svn: 68074

llvm-svn: 68021

productions (except the already broken ObjC cases like @class X,Y;) in 
the parser that can produce more than one Decl return a DeclGroup instead
of a Decl, etc.

This allows elimination of the Decl::NextDeclarator field, and exposes
various clients that should look at all decls in a group, but which were
only looking at one (such as the dumper, printer, etc).  These have been
fixed.

Still TODO:

1) there are some FIXME's in the code about potentially using
DeclGroup for better location info.
2) ParseObjCAtDirectives should return a DeclGroup due to @class etc.
3) I'm not sure what is going on with StmtIterator.cpp, or if it can
   be radically simplified now.
4) I put a truly horrible hack in ParseTemplate.cpp.

I plan to bring up #3/4 on the mailing list, but don't plan to tackle
#1/2 in the short term.

llvm-svn: 68002

Reintroduce r67870 (rval ref overloading), since I can't reproduce any test failures on i386 or x86_64. If this fails for someone, please contact me.

llvm-svn: 67999

llvm-svn: 67981

llvm-svn: 67978

to work around this.

llvm-svn: 67968

More improvements to namespace aliases. We now support everything except aliases in using directives.

llvm-svn: 67966

llvm-svn: 67964

llvm-svn: 67962

llvm-svn: 67961

pointer.  Its purpose in life is to be a glorified void*, but which does not
implicitly convert to void* or other OpaquePtr's with a different UID.

Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>.  Change the 
entire parser/sema interface to use DeclPtrTy instead of DeclTy*.  This
makes the C++ compiler enforce that these aren't convertible to other opaque
types.

We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
but I don't plan to do that in the short term.

The one outstanding known problem with this patch is that we lose the 
bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
bitmangle the success bit into the low bit of DeclPtrTy.  I will rectify
this with a subsequent patch.

llvm-svn: 67952

llvm-svn: 67932

llvm-svn: 67925

llvm-svn: 67923

llvm-svn: 67921

llvm-svn: 67915

 TranslationUnit

llvm-svn: 67913

SemaCXX//overload-member-call.cpp
SemaCXX//overloaded-operator.cpp
SemaTemplate//instantiate-method.cpp

llvm-svn: 67912

llvm-svn: 67911

llvm-svn: 67910

happy with just ASTContext, they don't need a TU.

llvm-svn: 67894

clang.cpp

llvm-svn: 67890

LHS type and the computation result type; this encodes information into 
the AST which is otherwise non-obvious.  Fix Sema to always come up with the 
right answer for both of these types.  Fix IRGen and the analyzer to 
account for these changes.  This fixes PR2601.  The approach is inspired 
by PR2601 comment 2.

Note that this changes real *= complex in CodeGen from a silent 
miscompilation to an explicit error.

I'm not really sure that the analyzer changes are correct, or how to 
test them... someone more familiar with the analyzer should check those 
changes.

llvm-svn: 67889

llvm-svn: 67887

syntax into extension warnings, and provide code-modification hints
showing how to fix the problem.

llvm-svn: 67885

instantiation for C++ typename-specifiers such as

  typename T::type

The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,

  typename T::template apply<U, V>

Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.

Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples. 

llvm-svn: 67875

llvm-svn: 67870

remove a redundant error in CodeGen.

llvm-svn: 67868

It is OK to cast to a private base class if the current member belongs to the class that the private base class is a base of:

class A {};
class B : private A {
  void f(B *b) { A* a = b; }
};

llvm-svn: 67860

Add a Class field to the base path element structure. This holds the record decl of the class taht the base is a base of.

llvm-svn: 67859

ir gen. No intended change in functionality.

llvm-svn: 67857

Implement checking for base class access. Right now it's overly conservative but that will change. (Also, protected isn't implemented right now).

llvm-svn: 67827

to a function or function pointer, it's probably because the user
forgot to put in parentheses () to call the function.

llvm-svn: 67826

llvm-svn: 67824

Remove the code insertion hint for implicit int. Too often, we're wrong about this hint, so it loses its usefulness. Maybe some day we can make the hint smart enough to be useful.

llvm-svn: 67823

llvm-svn: 67821