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
This method is intended to eventually replace the individual
Type::getAsXXXType<> methods.
The motivation behind this change is twofold:
1) Reduce redundant implementations of Type::getAsXXXType() methods. Most of
them are basically copy-and-paste.
2) By centralizing the implementation of the getAs<Type> logic we can more
smoothly move over to Doug Gregor's proposed canonical type smart pointer
scheme.
Along with this patch:
a) Removed 'Type::getAsPointerType()'; now clients use getAs<PointerType>.
b) Removed 'Type::getAsBlockPointerTypE()'; now clients use getAs<BlockPointerType>.
llvm-svn: 76098
Objective-C pointers to using ObjCObjectPointerType.
Now the checking for 'attribute ((nonnull))' in Sema doesn't emit an error when
trying to apply that attribute to a parameter that is an Objective-C pointer
(this is a regression).
To prevent this regression from occuring in the future, the 'nonnull.c' test was
moved to test/SemaObjC and renamed 'nonnull.m'. I also enhanced the tests to
show that function calls involved a NULL Objective-C pointer constant does not
trigger a warning. This is consistent with GCC, but should likely be fixed.
llvm-svn: 75856
This removes the static data/methods on ObjCObjectPointerType while preserving the nice API (no need to fiddle with ASTContext:-).
This patch also adds Type::isObjCBuiltinType().
This should be the last fairly large patch related to recrafting the ObjC type system. The follow-on patches should be fairly small.
llvm-svn: 75808
I don't love the name, however it simplifies the code and is a worthwhile change. If/when we come up with a better name, we can do a search/replace.
llvm-svn: 75650
Note: One day, it might be useful to consider adding this info to DeclGroup (as the comments in FunctionDecl/VarDecl suggest). For now, I think this works fine. I considered moving this to ValueDecl (a common ancestor of FunctionDecl/VarDecl/FieldDecl), however this would add overhead to EnumConstantDecl (which would burn memory and isn't necessary).
llvm-svn: 75635
- Declaration context of ParmVarDecls (that we got from the Declarator) was not their containing function.
- C++ out-of-line method definitions didn't get an access specifier.
Both were exposed by a crash when emitting a C++ method to a PCH file (assert at Decl::CheckAccessDeclContext()).
llvm-svn: 75597
warning: ‘OPT’ may be used uninitialized in this function
Now OPT is initialized to NULL. I'm not certain if this is the correct fix;
others please review.
llvm-svn: 75321
The idea is to segregate Objective-C "object" pointers from general C pointers (utilizing the recently added ObjCObjectPointerType). The fun starts in Sema::GetTypeForDeclarator(), where "SomeInterface *" is now represented by a single AST node (rather than a PointerType whose Pointee is an ObjCInterfaceType). Since a significant amount of code assumed ObjC object pointers where based on C pointers/structs, this patch is very tedious. It should also explain why it is hard to accomplish this in smaller, self-contained patches.
This patch does most of the "heavy lifting" related to moving from PointerType->ObjCObjectPointerType. It doesn't include all potential "cleanups". The good news is additional cleanups can be done later (some are noted in the code). This patch is so large that I didn't want to include any changes that are purely aesthetic.
By making the ObjC types truly built-in, they are much easier to work with (and require fewer "hacks"). For example, there is no need for ASTContext::isObjCIdStructType() or ASTContext::isObjCClassStructType()! We believe this change (and the follow-up cleanups) will pay dividends over time.
Given the amount of code change, I do expect some fallout from this change (though it does pass all of the clang tests). If you notice any problems, please let us know asap! Thanks.
llvm-svn: 75314
in their order of construction for each class and use it
to to check on propery order of base class construction
under -Wreorder option.
llvm-svn: 75270
function template. Most of the change here is in factoring out the
common bits used for template argument deduction from a function call
and when taking the address of a function template.
llvm-svn: 75044
Steve Naroff