Commit Graph

11 Commits

Author SHA1 Message Date
Fariborz Jahanian 113b8ad7cf Reverse a partial fix patch for radar 7214820. It broke some code and
I don't have time to refix it for now.

llvm-svn: 95733
2010-02-10 00:32:12 +00:00
Fariborz Jahanian 04477f3de9 Merge block/function pointer types with objc's __weak
attribute properly and avoid bogus warning. This is
an objective-c fix only. objective-c++ follows different code
pass and requires separate fix (which will come at a later time).
Fixes radar 7214820.

llvm-svn: 95571
2010-02-08 21:09:39 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Fariborz Jahanian 0399c1c9c0 Change tests to use clang -cc1...
llvm-svn: 91297
2009-12-14 17:36:25 +00:00
Steve Naroff 7cae42b07a This patch includes a conceptually simple, but very intrusive/pervasive change.
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
2009-07-10 23:34:53 +00:00
Fariborz Jahanian 991a2b1933 Diagnose misuse of __strong attribute in a redeclaration.
llvm-svn: 72737
2009-06-02 20:58:58 +00:00
Fariborz Jahanian 6ab4375f87 Issue diagnostics on __weak attribute mismatch.
Fixes an error recovery issue which caused a crash.

llvm-svn: 72733
2009-06-02 18:32:00 +00:00
Eli Friedman 179f2b9ec7 Remove test which doesn't pass with gcc.
llvm-svn: 72714
2009-06-02 05:24:36 +00:00
Fariborz Jahanian 2d725b19da This patch attempts to fix the merging of __strong/__weak attributes
in merge_types. It is incomplete. We probably want to issue 
a warning if user attempts to change the attribute from __weak to
__strong or vice-vera. It also assumes that a __weak/__strong
attribute can not be specified with other (currently one) type
attriute. 

llvm-svn: 72711
2009-06-02 01:40:22 +00:00
Eli Friedman dcca6333c6 Disable type merging with gc attributes. This has a number of nasty
properties at the moment:

1. It allows stuff like "__strong id x; __weak id x;".

2. For constructs like "__strong id x; id x;", subsequent references to 
x lose the objc_gc attribute.

3. This incorrectly allows merges involving the address_space attribute.

4. Constructs like "id x; /* some code using x */ __weak id x;" don't 
apply the objc_gc attribute consistently to all uses of x.

The first three can probably be fixed relatively easily; the fourth 
would be extremely difficult to fix.

llvm-svn: 72683
2009-06-01 01:22:52 +00:00
Fariborz Jahanian 3453f7d410 Fix decl type merges when they have
__string/__weak attributes.

llvm-svn: 69229
2009-04-15 21:54:48 +00:00