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

llvm-svn: 64185

If the target cannot issue a copy for the given source and dest registers, abort instead of silently continue.

llvm-svn: 64184

llvm-svn: 64177

llvm-svn: 64175

llvm-svn: 64173

llvm-svn: 64169

llvm-svn: 64168

Implement Sebastian's idea for simplifying our handling of the greater-than operator/delimiter. Also, clean up after ourselves following a failed parse of a template-argument-list

llvm-svn: 64166

llvm-svn: 64164

llvm-svn: 64163

llvm-svn: 64162

Use the new cleanup infrastructure for VLAs. The next iteration of patches will remove the old Obj-C EH cleanup code.

llvm-svn: 64161

llvm-svn: 64160

llvm-svn: 64159

llvm-svn: 64158

llvm-svn: 64157

llvm-svn: 64156

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

Fix PR 2514: Do not flag dead initializations for variables initialized to a constant global variable.

llvm-svn: 64149

llvm-svn: 64148

llvm-svn: 64147

Deallocate the StringLiteral itself in StringLiteral::Destroy() and deallocate the string data before running StringLiteral's destructor.

llvm-svn: 64146

llvm-svn: 64145

llvm-svn: 64144

llvm-svn: 64143

even if the underlying operand is NULL. This may happen in debugging context
within opt with partial loop unrolling (see test/Transforms/LoopUnroll/partial.ll).
After this fix I can resubmit the (backed out) r63459:
* lib/VMCore/AsmWriter.cpp: use precise accessors.

llvm-svn: 64142

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

llvm-svn: 64136

llvm-svn: 64132

llvm-svn: 64131

llvm-svn: 64129

llvm-svn: 64128

llvm-svn: 64127

llvm-svn: 64126