Added a FIXME to handle 'rethrow' check.

llvm-svn: 64308

Rename Sema::hasSameUnqualifiedType to QualType::isSameIgnoringQalifiers

llvm-svn: 64307

pointer-to-member-data non-type template parameters. Also, get
consistent about what it means to returned a bool from
CheckTemplateArgument.

llvm-svn: 64305

non-type template parameters that are references to functions or
pointers to member functions. Did a little bit of refactoring so that
these two cases, along with the handling of non-type template
parameters that are pointers to functions, are handled by the same
path. 

Also, tweaked FixOverloadedFunctionReference to cope with member
function pointers. This is a necessary step for getting all of the fun
member pointer conversions working outside of template arguments, too.

llvm-svn: 64277

template parameters that have reference type. Effectively, we're doing
a very limited form of reference binding here.

llvm-svn: 64270

non-type template parameters of pointer-to-object and
pointer-to-function type. The most fun part of this is the use of
overload resolution to pick a function from the set of overloaded
functions that comes in as a template argument.

Also, fixed two minor bugs in this area:
  - We were allowing non-type template parameters of type pointer to
  void.
  - We weren't patching up an expression that refers to an overloaded
  function set via "&f" properly.

We're still not performing complete checking of the expression to be
sure that it is referring to an object or function with external
linkage (C++ [temp.arg.nontype]p1).

llvm-svn: 64266

integral or enumeration type.

llvm-svn: 64256

arrays and other structs/unions as an extension. Downgrade our error
to a warning. Fixes PR3540.

llvm-svn: 64239

arguments. This commit covers checking and merging default template
arguments from previous declarations, but it does not cover the actual
use of default template arguments when naming class template
specializations.

llvm-svn: 64229

llvm-svn: 64223

disambiguation contexts, so that we properly parse template arguments
such as

  A<int()>

as type-ids rather than as expressions. Since this can be confusing
(especially when the template parameter is a non-type template
parameter), we try to give a friendly error message.

Almost, eliminate a redundant error message (that should have been a
note) and add some ultra-basic checks for non-type template
arguments.

llvm-svn: 64189

template parameters.

llvm-svn: 64188

template parameters when performing semantic analysis of a template-id
naming a class template specialization.

llvm-svn: 64185

llvm-svn: 64162

to tell it that it wasn't (directly) designated. This way, we unwind
back to the explicit initializer list properly rather than getting
stuck in the wrong subobject. Fixes llvm.org/PR3519

llvm-svn: 64155

representation for template arguments. Also simplifies the interface
for ActOnClassTemplateSpecialization and eliminates some annoying
allocations of TemplateArgs.

My attempt at smart pointers for template arguments lists is
relatively lame. We can improve it once we're sure that we have the
right representation for template arguments.

llvm-svn: 64154

to a class template. For example, the template-id 'vector<int>' now
has a nice, sugary type in the type system. What we can do now:

  - Parse template-ids like 'vector<int>' (where 'vector' names a
    class template) and form proper types for them in the type system.
  - Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly,
    using (sadly) a bool in the parser to tell it whether '>' should
    be treated as an operator or not.

This is a baby-step, with major problems and limitations:
  - There are currently two ways that we handle template arguments
  (whether they are types or expressions). These will be merged, and,
  most likely, TemplateArg will disappear.
  - We don't have any notion of the declaration of class template
  specializations or of template instantiations, so all template-ids
  are fancy names for 'int' :)

llvm-svn: 64153

References are not objects; implement this in Type::isObjectType().

llvm-svn: 64152

llvm-svn: 64151

llvm-svn: 64145

than a Decl, which gives us some more flexibility to express the
results with the type system. There are no clients using this
flexibility yet, but it's meant to be able to describe qualified names
as written in the source (e.g., "foo::type") or template-ids that name
a class template specialization (e.g., "std::vector<INT>").

DeclSpec's TST_typedef has become TST_typename, to reflect its use to
describe types found by name (that may or may not be typedefs). The
type representation of a DeclSpec with TST_typename is an opaque
QualType pointer. All users of TST_typedef, both direct and indirect,
have been updated for these changes.

llvm-svn: 64141

llvm-svn: 64085

llvm-svn: 64081

llvm-svn: 64047

llvm-svn: 64029

llvm-svn: 63998

- Made allocation of Stmt objects using vanilla new/delete a *compiler
  error* by making this new/delete "protected" within class Stmt.
- Now the only way to allocate Stmt objects is by using the new
  operator that takes ASTContext& as an argument.  This ensures that
  all Stmt nodes are allocated from the same (pool) allocator.
- Naturally, these two changes required that *all* creation sites for
  AST nodes use new (ASTContext&).  This is a large patch, but the
  majority of the changes are just this mechanical adjustment.
- The above changes also mean that AST nodes can no longer be
  deallocated using 'delete'.  Instead, one most do
  StmtObject->Destroy(ASTContext&) or do
  ASTContextObject.Deallocate(StmtObject) (the latter not running the
  'Destroy' method).

Along the way I also...
- Made CompoundStmt allocate its array of Stmt* using the allocator in
  ASTContext (previously it used std::vector).  There are a whole
  bunch of other Stmt classes that need to be similarly changed to
  ensure that all memory allocated for ASTs comes from the allocator
  in ASTContext.
- Added a new smart pointer ExprOwningPtr to Sema.h.  This replaces
  the uses of llvm::OwningPtr within Sema, as llvm::OwningPtr used
  'delete' to free memory instead of a Stmt's 'Destroy' method.

Big thanks to Doug Gregor for helping with the acrobatics of making
'new/delete' private and the new smart pointer ExprOwningPtr!

llvm-svn: 63997

llvm-svn: 63987

llvm-svn: 63983

llvm-svn: 63975

redeclarations. For example, checks that a class template
redeclaration has the same template parameters as previous
declarations.

Detangled class-template checking from ActOnTag, whose logic was
getting rather convoluted because it tried to handle C, C++, and C++
template semantics in one shot.

Made some inroads toward eliminating extraneous "declaration does not
declare anything" errors by adding an "error" type specifier.

llvm-svn: 63973

ASTContext. This required changing all clients to pass in the ASTContext& to the
constructor of StringLiteral. I also changed all allocations of StringLiteral to
use new(ASTContext&).

Along the way, I updated a bunch of new()'s in StmtSerialization.cpp to use the
allocator from ASTContext& (not complete).

llvm-svn: 63958

matching member exists. Thanks to Piotr Rak for reporting the problem!

llvm-svn: 63939

Also, put Objective-C protocols into their own identifier
namespace. Otherwise, we find protocols when we don't want to in C++
(but not in C).

llvm-svn: 63877

llvm-svn: 63866

extension. The interaction with designated initializers is a
bit... interesting... but we follow GNU's lead and don't permit too
much crazy code in this area.

Also, make the "excess initializers" error message a bit more
informative.

Addresses PR2561: http://llvm.org/bugs/show_bug.cgi?id=2561

llvm-svn: 63785

llvm-svn: 63784

llvm-svn: 63779

DeclTy*, not TypeTy*.

llvm-svn: 63756

llvm-svn: 63750