storage for that partial diagnostic via the ASTContext's
BumpPtrAllocator rather than using up slots in the ASTContext's
cache. Now that we do this, we don't have to worry about destroying
dependent diagnostics when destroying a DependentStoredDeclsMap.

llvm-svn: 99854

cache of PartialDiagnostic::Storage objects into an allocator within
the ASTContext. This eliminates a significant amount of malloc
traffic, for a 10% performance improvement in -fsyntax-only wall-clock
time with 403.gcc's combine.c.

Also, eliminate the RequireNonAbstractType hack I put in earlier,
which was but a symptom of this larger problem.

Fixes <rdar://problem/7806091>.

llvm-svn: 99849

templates.  So delay access-control diagnostics when (for example) the target
of a friend declaration is a specific specialization of a template.

I was surprised to find that this was required for an access-controlled selfhost.

llvm-svn: 99383

I'm expecting this portion of the AST to grow and change, and I'd like to
be able to do that with minimal recompilation.  If this proves unnecessary
when access control is fully-implemented, I'll fold the classes back into
DeclCXX.h.

llvm-svn: 98249

injected class name of a class template or class template partial specialization.
This is a non-canonical type;  the canonical type is still a template 
specialization type.  This becomes the TypeForDecl of the pattern declaration,
which cleans up some amount of code (and complicates some other parts, but
whatever).

Fixes PR6326 and probably a few others, primarily by re-establishing a few
invariants about TypeLoc sizes.     

llvm-svn: 98134

trigger access control or one of the many assertions we have for valid
access specifiers.

llvm-svn: 97767

declaration. This is the trivial part of PR6365.

llvm-svn: 96792

llvm-svn: 96444

storing the set of StoredDeclsMaps in an internal vector of void*.
This isn't an ideal solution, but for the time being this fixes a
major memory leak with these DenseMaps not being freed.

Fixes: <rdar://problem/7634755>
llvm-svn: 95861

translation unit.  This is temporary for function and block parameters;
template parameters can just stay this way, since Templates aren't
DeclContexts.  This gives us the nice property that everything created
in a record DC should have access in C++.

llvm-svn: 94122

Triggers lots of assertions about missing access information;  fix them.

Will actually consume this information soon.

llvm-svn: 94038

to merge the local instantiation scope with the outer local
instantiation scope, so that we can instantiate declarations from the
function owning the local class. Fixes an assert while instantiating
Boost.MPL's BOOST_MPL_ASSERT_MSG.

llvm-svn: 93651

objective-c++ mode and also removed dead-code in this area.
(fixes radar 7456710).

llvm-svn: 91081

are a couple of O(n^2) operations in this, some analogous to the usual O(n^2)
redeclaration problem and some not.  In particular, retroactively removing
shadow declarations when they're hidden by later decls is pretty unfortunate.
I'm not yet convinced it's worse than the alternative, though.

llvm-svn: 91045

DeclContext, so they don't completely disappear from the AST.

I don't particularly like this fix, but I don't see any obviously better way
to deal with it, and I think it's pretty clearly an improvement; comments
welcome.

llvm-svn: 90835

llvm-svn: 90313

ASTContext instead of malloc.  Besides reducing malloc traffic, this
also removes a source of memory leaks when using a BumpPtrAllocator
for the allocator of ASTContext.  There are still leaks when using
MallocAllocator because Decl::Destroy() isn't fully finished.

Fixes: <rdar://problem/7431556>
llvm-svn: 90174

llvm-svn: 90078

llvm-svn: 89546

two classes, one for typenames and one for values;  this seems to have some
support from Doug if not necessarily from the extremely-vague-on-this-point
standard.  Track the location of the 'typename' keyword in a using-typename
decl.  Make a new lookup result for unresolved values and deal with it in
most places.

llvm-svn: 89184

llvm-svn: 89170

current DeclContext.  These "imaginary" declarations pose issues for
clients searching DeclContext for actual declarations.  Instead,
register them for name lookup, and add the ObjCInterfaceDecl later to
the DeclContext when we hit an actual @interface declaration.

This also fixes a bug where the invariant that the Decls in a
DeclContext are sorted in order of their appearance is no longer
violated.  What could happen is that an @class causes an
ObjCInterfaceDecl to get added first to the DeclContext, then the
ObjCClassDecl itself is added, and then later the SourceLocation of
the ObjCInterfaceDecl is updated with the correct location (which is
later in the file).  This breaks an assumed invariant in
ResolveLocation.cpp (and possibly other clients).

llvm-svn: 89160

decl, create shadow declarations and put them in scope like normal.
Work in progress.

llvm-svn: 89048

in the DeclaratorInfo, if one is present.

Preserve source information through template instantiation.  This is made
more complicated by the possibility that ParmVarDecls don't have DIs, which
is possibly worth fixing in the future.

Also preserve source information for function parameters in ObjC method
declarations.

llvm-svn: 84971

apparently because using directives aren't quite working correctly.

llvm-svn: 83184

llvm-svn: 82088

all of the parent DeclContexts that aren't represented within the
Scope chain. This fixes some name-lookup problems in out-of-line
definitions of members of nested classes.

llvm-svn: 81451

llvm-svn: 81346

decl list, and remove some workarounds that were due to this.  Thanks to Eli for
pointing this out and providing the test case.

llvm-svn: 80745

existing declaration chains.

llvm-svn: 80636

llvm-svn: 80438

llvm-svn: 80420

llvm-svn: 80415

declarations of same, introduce a single AST class and add appropriate bits
(encoded in the namespace) for whether a decl is "real" or not.  Much hackery
about previously-declared / not-previously-declared, but it's essentially
mandated by the standard that friends alter lookup, and this is at least
fairly non-intrusive.

Refactor the Sema methods specific to friends for cleaner flow and less nesting.

Incidentally solve a few bugs, but I remain confident that we can put them back.

llvm-svn: 80353

llvm-svn: 80336

When checking whether one declaration context encloses another, make sure to look at the primary contexts. Thanks to Eli for the test case

llvm-svn: 80212

the AST, and create such declarations.

llvm-svn: 78719

FriendFunctionDecl, and create instances as appropriate.

The design of FriendFunctionDecl is still somewhat up in the air;  you can
befriend arbitrary types of functions --- methods, constructors, etc. ---
and it's not clear that this representation captures that very well.
We'll have a better picture when we start consuming this data in access
control.

llvm-svn: 78653

  Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
  Type::getAsRecordType() -> Type::getAs<RecordType>()
  Type::getAsPointerType() -> Type::getAs<PointerType>()
  Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
  Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
  Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
  Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
  Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
  Type::getAsTagType() -> Type::getAs<TagType>()
  
And remove Type::getAsReferenceType(), etc.

This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.

llvm-svn: 77510

until Doug Gregor's Type smart pointer code lands (or more discussion occurs).
These methods just call the new Type::getAs<XXX> methods, so we still have
reduced implementation redundancy. Having explicit getAsXXXType() methods makes
it easier to set breakpoints in the debugger.

llvm-svn: 76193