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

Replaced Type::getAsLValueReferenceType(), Type::getAsRValueReferenceType(), Type::getAsMemberPointerType(), Type::getAsTagType(), and Type::getAsRecordType() with their Type::getAs<XXX> equivalents.

llvm-svn: 76139

Remove ASTContext parameter from DeclContext's methods. This change cascaded down to other Decl's methods and changes to call sites started "escalating".
Timings using pre-tokenized "cocoa.h" showed only a ~1% increase in time run between and after this commit.

llvm-svn: 74506

Timings showed no significant difference before and after the commit.

llvm-svn: 74504

llvm-svn: 74502

The implementations of these methods can Use Decl::getASTContext() to get the ASTContext.

This commit touches a lot of files since call sites for these methods are everywhere.
I used pre-tokenized "carbon.h" and "cocoa.h" headers to do some timings, and there was no real time difference between before the commit and after it.

llvm-svn: 74501

-Introduce Decl::getASTContext() which returns the reference from the TranslationUnitDecl that it is contained in.

The general idea is that Decls can point to their own ASTContext so that it is no longer required to "manually" keep track and make sure that you pass the correct ASTContext to Decls' methods, e.g. methods like Decl::getAttrs should eventually not require a ASTContext parameter.

llvm-svn: 74434

llvm-svn: 74269

templates.

For example, this now type-checks (but does not instantiate the body
of deref<int>):

  template<typename T> T& deref(T* t) { return *t; }

  void test(int *ip) {
    int &ir = deref(ip);
  }

Specific changes/additions:
  * Template argument deduction from a call to a function template.
  * Instantiation of a function template specializations (just the
  declarations) from the template arguments deduced from a call.
  * FunctionTemplateDecls are stored directly in declaration contexts
  and found via name lookup (all forms), rather than finding the
  FunctionDecl and then realizing it is a template. This is
  responsible for most of the churn, since some of the core
  declaration matching and lookup code assumes that all functions are
  FunctionDecls.

llvm-svn: 74213

llvm-svn: 73812