No functionality change (really).

llvm-svn: 68726

StoredDeclsMap, instead of using the it's-an-array-or-its-a-map
trick. I'll verify that performance isn't impacted later; for now, I
need the common representation.

llvm-svn: 68715

llvm-svn: 68680

llvm-svn: 68646

llvm-svn: 68634

value of its subexpressions unless it is a comma (in which case it doesn't
consume the left subexpression).

llvm-svn: 68628

llvm-svn: 68586

llvm-svn: 68548

llvm-svn: 68533

Simplify the addition of a case statement to a switch.

Fix -print-stats for attribute-qualified types.

llvm-svn: 68522

had too many false positives in the analyzer.

llvm-svn: 68492

Ignore plus operands when looking up the operand number from a named operand. This matches llvm-gcc and fixes PR3908.

llvm-svn: 68371

llvm-svn: 68346

objc's continuation class.

llvm-svn: 68339

llvm-svn: 68301

class which was exposed by implementation of 
objc2's nonfragile abi code gen.

llvm-svn: 68259

class.

llvm-svn: 68234

llvm-svn: 68232

heuristics to determine when it's useful to desugar a type for display
to the user. Introduce two C++-specific heuristics:

  - For a qualified type (like "foo::bar"), only produce a new
    desugred type if desugaring the qualified type ("bar", in this
    case) produces something interesting. For example, if "foo::bar"
    refers to a class named "bar", don't desugar. However, if
    "foo::bar" refers to a typedef of something else, desugar to that
    something else. This gives some useful desugaring such as
    "foo::bar (aka 'int')".
  - Don't desugar class template specialization types like
    "basic_string<char>" down to their underlying "class
    basic_string<char, char_traits<char>, allocator<char>>, etc.";
    it's better just to leave such types alone. 

Update diagnostics.html with some discussion and examples of type
preservation in C++, showing qualified names and class template
specialization types.

llvm-svn: 68207

should only be an error if that value is consumed. This fix was largely
accomplished by moving 'isConsumedExpr' back to ParentMap.

llvm-svn: 68195

types.  It is no longer needed now that the code generator 
re-lays-out interfaces if they are defines after being laid out
from a forward decl.

llvm-svn: 68194

distinguish between the true and false branches for path-sensitive analyses.

llvm-svn: 68185

llvm-svn: 68171

specifiers that terminate in a simple-template-id, e.g.,

  typename MetaFun::template apply<T1, T2>

Also, implement template instantiation for dependent
nested-name-specifiers that involve unresolved identifiers, e.g.,

  typename T::type::type

llvm-svn: 68166

llvm-svn: 68140

template template parameters and dependent template names. For
example, the oft-mentioned

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

can now be instantiated, with the appropriate name lookup for "apply".

llvm-svn: 68128

llvm-svn: 68122

llvm-svn: 68110

In a case like:

@class foo;
foo *P;

addRecordToClass was making an empty shadow struct for the foo interface and
completing it.  Later when an:

@interface foo
...
@endif

foo *Q;

was seen, ASTContext::addRecordToClass would think that foo was already laid
out and not lay out the definition.  This fixes it to create a forward declared
struct the first time around, then complete it when the definition is seen.

Note that this causes two tests to regress, because something is trying to get
the size of the forward declared structs returned by this.  Previously, this
would end up getting a size of zero but now it properly dies.  I'm not sure
what the right solution is for this, so I xfailed the tests.

Fariborz, please take a look at this.  The testcase in rdar://6676794 now gets
farther, but dies later because the objc ivar is not assigned a field number.

As an aside, I really don't like the fact that the objc front-end is creating
shadow C structs for ObjC types.  This seems like an implementation detail of
the code generator that could be fixed by better factoring of the extant code.

llvm-svn: 68106

llvm-svn: 68103

Fix BuildAggrIvarLayout to not access vectors out of range.

llvm-svn: 68101

llvm-svn: 68098

llvm-svn: 68094

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

llvm-svn: 68075

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

assume that @catch blocks are never executed.

llvm-svn: 68072

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

llvm-svn: 68000