encountered. Mixing up the decls is unintuitive, and confuses the AST
destruction code. Fixes PR2360.
Note that there is a need to look up the characteristics and
declarations of a function associated with a particular name or decl,
but the original swapping code doesn't solve it properly.
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-May/001644.html is one
suggestion for how to fix that.
llvm-svn: 51584
Fixed a bug in ParmVarDecl::param_end(): Handle the case where there are no
ParmVarDecls for a FunctionDecl, but its function prototype has formal arguments
(can happen with typedefs).
llvm-svn: 51297
1) Sema::ParseAST now constructs a TranslationUnit object to own the top-level Decls, which releases the top-level Decls upon exiting ParseAST.
2) Bug fix: TranslationUnit::~TranslationUnit handles the case where a Decl is added more than once as a top-level Decl.
3) Decl::Destroy is now a virtual method, obviating the need for a special dispatch based on DeclKind.
3) FunctionDecl::Destroy now releases its Body using its Destroy method.
4) Added Stmt::Destroy and Stmt::DestroyChildren, which recursively delete the child ASTs of a Stmt and call their dstors. We may need to special case dstor/Destroy methods for particular Stmt subclasses that own other dynamically allocated objects besides AST nodes.
5) REGRESSION: We temporarily are not deallocating attributes; a FIXME is provided.
llvm-svn: 51286
-NamespaceDecl for the AST
-Checks for name clashes between namespaces and tag/normal declarations.
This commit doesn't implement proper name lookup for namespaces.
llvm-svn: 50321
DeclContext *CtxDecl -> DeclContext *DeclCtx
DeclContext *CD -> DeclContext *DC
It makes the code more consistent."
Patch by Zhongxing Xu!
llvm-svn: 50105
-Added TranslationUnitDecl class to serve as top declaration context
-ASTContext gets a TUDecl member and a getTranslationUnitDecl() function
-All ScopedDecls get the TUDecl as DeclContext when declared at global scope
llvm-svn: 49855
This is a fairly mechanical/large change. As a result, I avoided making any changes/simplifications that weren't directly related. I did break two Analysis tests. I also have a couple FIXME's in UninitializedValues.cpp. Ted, can you take a look? If the bug isn't obvious, I am happy to dig in and fix it (since I broke it).
llvm-svn: 49748
#1: To be consistent with FieldDecl::getContextDecl(), which serves the same purpose.
#2: From my perspective, getContext() is too general (and used by several other classes for different purposes).
llvm-svn: 49224
-Added ContextDecl (no TranslationUnitDecl)
-ScopedDecl class has a ContextDecl member
-FieldDecl class has a ContextDecl member, so that a Field or a ObjCIvar can be traced back to their RecordDecl/ObjCInterfaceDecl easily
-FunctionDecl, ObjCMethodDecl, TagDecl, ObjCInterfaceDecl inherit from ContextDecl. With TagDecl as ContextDecl, enum constants have a EnumDecl as their context.
-Moved Decl class to a "DeclBase.h" along with ContextDecl class
-CurContext is handled by Sema
llvm-svn: 49208
- Added a DenseMap to associate an IdentifierInfo with the ObjCCompatibleAliasDecl.
- Renamed LookupScopedDecl->LookupDecl and changed it's return type to Decl. Also added lookup for ObjCCompatibleAliasDecl's.
- Removed Sema::LookupInterfaceDecl(). Converted clients to used LookupDecl().
- Some minor indentation changes.
Will deal with ObjCInterfaceDecl and getObjCInterfaceDecl() in a separate commit...
llvm-svn: 49058
Fix objc ivar lookup. Ivar lookup should occur between lookup
of method-local values and lookup of globals. Emulate this with
some logic in the handling of Sema::ActOnIdentifierExpr.
Two todo's left:
1) sema shouldn't turn a bare reference to an ivar into "self->ivar"
in the AST. This is a hack.
2) The new ScopedDecl::isDefinedOutsideFunctionOrMethod method does
not correctly handle typedefs and enum constants yet.
llvm-svn: 48972
lib dir and move all the libraries into it. This follows the main
llvm tree, and allows the libraries to be built in parallel. The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in. This speeds
up parallel builds, particularly incremental ones.
llvm-svn: 48402
Argyrios Kyrtzidis