llvm-svn: 64160

llvm-svn: 64159

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

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

llvm-svn: 64149

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

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

llvm-svn: 64128

llvm-svn: 64127

llvm-svn: 64105

llvm-svn: 64100

llvm-svn: 64099

Add a simplified EmitJumpThroughFinally and use it in CGObjC in preparation of making it use the cleanup stack.

llvm-svn: 64098

llvm-svn: 64096

llvm-svn: 64095

llvm-svn: 64092

llvm-svn: 64087

llvm-svn: 64086

llvm-svn: 64085

llvm-svn: 64081

llvm-svn: 64080

If people could beat on it and let me know if there are any new
semantics required by newer language standards or DRs or any little
details I goofed on, I'd be happy to fix any issues found.

llvm-svn: 64079

llvm-svn: 64074

llvm-svn: 64072

llvm-svn: 64071

llvm-svn: 64069

llvm-svn: 64068

llvm-svn: 64064

llvm-svn: 64063

the "system dirs win over user dirs" logic to framework and headermap
search locations as well as normal directories.  This means that
clang t.m -F/System/Library/Frameworks  will treat /System/Library/Frameworks
as a system directory not a user directory.  If you use -v, the difference is:

Before:
ignoring nonexistent directory "/usr/libdata/gcc41"
ignoring duplicate framework "/System/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:

After:
ignoring nonexistent directory "/usr/libdata/gcc41"
ignoring duplicate directory "/System/Library/Frameworks"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:

This fixes rdar://6566429.

llvm-svn: 64060

llvm-svn: 64059