uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
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
by DeclContexts (always) rather than by statements.
DeclContext currently goes out of its way to avoid destroying any
Decls that might be owned by a DeclGroupOwningRef. However, in an
error-recovery situation, a failure in a declaration statement can
cause all of the decls in a DeclGroupOwningRef to be destroyed after
they've already be added into the DeclContext. Hence, DeclContext is
left with already-destroyed declarations, and bad things happen. This
problem was causing failures that showed up as assertions on x86 Linux
in test/Parser/objc-forcollection-neg-2.m.
llvm-svn: 64474
This will simplify runtime replacement of ASTContext's allocator. Keeping the allocator private (and removing getAllocator() entirely) is also goodness.
llvm-svn: 63135
Chandler Carruth