failures that involve malformed types, e.g., "typename X::foo" where
"foo" isn't a type, or "std::vector<void>" that doens't instantiate
properly.

Similarly, be a bit smarter in our handling of ambiguities that occur
in Sema::getTypeName, to eliminate duplicate error messages about
ambiguous name lookup.

This eliminates two XFAILs in test/SemaCXX, one of which was crying
out to us, trying to tell us that we were producing repeated error
messages.

llvm-svn: 68251

llvm-svn: 68110

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

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: 67818

Factor the member access specifier setting code into its own function. No intended functionality change.

llvm-svn: 67725

llvm-svn: 67722

specializations can be treated as a template. Finally, we can parse
and process the first implementation of Fibonacci I wrote!

Note that this code does not handle all of the cases where
injected-class-names can be treated as templates. In particular,
there's an ambiguity case that we should be able to handle (but
can't), e.g.,

  template <class T> struct Base { }; 
  template <class T> struct Derived : Base<int>, Base<char> {
    typename Derived::Base b;       // error: ambiguous
    typename Derived::Base<double> d;  // OK 
  };

llvm-svn: 67720

Also, fix fallout from the change.

llvm-svn: 67717

templates, including in-class initializers. For example:

  template<typename T, T Divisor>
  class X {
  public:
    static const T value = 10 / Divisor;
  };

instantiated with, e.g.,

  X<int, 5>::value

to get the value '2'.

llvm-svn: 67715

llvm-svn: 67710

the declarations of member classes are instantiated when the owning
class template is instantiated. The definitions of such member classes
are instantiated when a complete type is required.

This change also introduces the injected-class-name into a class
template specialization.

llvm-svn: 67707

llvm-svn: 67687

incomplete types. RequireCompleteType is needed when the type may be
completed by instantiating a template.

llvm-svn: 67643

class C {
  void g(C c);

  virtual void f() = 0;
};

In this case, C is not known to be abstract when doing semantic analysis on g. This is done by recursively traversing the abstract class and checking the types of member functions. 

llvm-svn: 67594

a class template. At present, we can only instantiation normal
methods, but not constructors, destructors, or conversion operators.

As ever, this contains a bit of refactoring in Sema's type-checking. In
particular:

  - Split ActOnFunctionDeclarator into ActOnFunctionDeclarator
    (handling the declarator itself) and CheckFunctionDeclaration
    (checking for the the function declaration), the latter of which
    is also used by template instantiation.
  - We were performing the adjustment of function parameter types in
    three places; collect those into a single new routine.
  - When the type of a parameter is adjusted, allocate an
    OriginalParmVarDecl to keep track of the type as it was written.
  - Eliminate a redundant check for out-of-line declarations of member
    functions; hide more C++-specific checks on function declarations
    behind if(getLangOptions().CPlusPlus).

llvm-svn: 67575

More improvements to abstract type checking. Handle arrays correctly, and make sure to check parameter types before they decay.

llvm-svn: 67550

llvm-svn: 67542

library function, accept this declaration and pretend that we do not
know that this is a library function. autoconf depends on this
(broken) behavior.

llvm-svn: 67541

prototype. Thanks Eli!

llvm-svn: 67533

llvm-svn: 67530

llvm-svn: 67476

Keep track of whether a class is abstract or not. This is currently only used for the __is_abstract type trait.

llvm-svn: 67461

there is a previous declaration marked "static". This fixes PR3645.

llvm-svn: 67336

llvm-svn: 67316

  F f;

where F is a typedef of a function type, then the function "f" has a
prototype. This is a slight tweak to Chris's suggested fix in
PR3817. Fixes PR3817 and PR3840.

llvm-svn: 67313

dependent qualified-ids such as

  Fibonacci<N - 1>::value

where N is a template parameter. These references are "unresolved"
because the name is dependent and, therefore, cannot be resolved to a
declaration node (as we would do for a DeclRefExpr or
QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to
DeclRefExprs, QualifiedDeclRefExprs, etc.

Also, be a bit more careful about keeping only a single set of
specializations for a class template, and instantiating from the
definition of that template rather than a previous declaration. In
general, we need a better solution for this for all TagDecls, because
it's too easy to accidentally look at a declaration that isn't the
definition.

We can now process a simple Fibonacci computation described as a
template metaprogram.

llvm-svn: 67308

specialization names. This way, we keep track of sugared types like

  std::vector<Real>

I believe we are now using QualifiedNameTypes everywhere we can. Next
step: QualifiedDeclRefExprs.

llvm-svn: 67268

qualified name, e.g., 

  foo::x

so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.

The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
 
  ::foo::bar::x

The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled). 

The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).

Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.

llvm-svn: 67265

Type pointer. This allows our nested-name-specifiers to retain more
information about the actual spelling (e.g., which typedef did the
user name, or what exact template arguments were used in the
template-id?). It will also allow us to have dependent
nested-name-specifiers that don't map to any DeclContext.

llvm-svn: 67140

no functionality change.

llvm-svn: 67128

quite as great as it sounds, because, while we can refer to the
enumerator values outside the template, e.g.,

  adder<long, 3, 4>::value

we can't yet refer to them with dependent names, so no Fibonacci
(yet). 

InstantiateClassTemplateSpecialization is getting messy; next commit
will put it into a less-ugly state.

llvm-svn: 67092

llvm-svn: 67045

Remove ActiveScope (revert http://llvm.org/viewvc/llvm-project?view=rev&revision=65694 and http://llvm.org/viewvc/llvm-project?view=rev&revision=66741).

Will replace with something better today...

llvm-svn: 66893

llvm-svn: 66835

be CompoundStmts. I think this is a valid assumption, and felt that the API
should reflect it. Others please validate this assumption to make sure I didn't
break anything.

llvm-svn: 66814

class members to the corresponding in-class declaration.

Diagnose the erroneous use of 'static' on out-of-line definitions of
class members. 

llvm-svn: 66740

Move most of the checking from ActOnCXXMemberDeclarator to other, more general routines. This is a step toward separating the checking logic from Declarators, which in turn is required for template instantiation.

llvm-svn: 66734

Make sure that we set the access specifier for an instantiated FieldDecl, and that the aggregate and POD flags for an instantiated class template are updated based on instantiation of a FieldDecl

llvm-svn: 66701

llvm-svn: 66696