[cfe-commits] r75314 - in /cfe/trunk: include/clang/AST/ include/clang/Analysis/PathSensitive/ lib/AST/ lib/Analysis/ lib/CodeGen/ lib/Frontend/ lib/Sema/ test/CodeGenObjC/ test/PCH/ test/SemaObjC/ test/SemaObjCXX/

[steve naroff]

On Jul 10, 2009, at 8:56 PM, Fariborz Jahanian wrote:

>
> On Jul 10, 2009, at 4:35 PM, Steve Naroff wrote:
>
>> Author: snaroff
>> Date: Fri Jul 10 18:34:53 2009
>> New Revision: 75314
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=75314&view=rev
>> Log:
>> 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.
>>
>>
>
> Great Steve. It sure was heck of an effort.
>
> Started with BlastApp. It asserts in many places. A sample is:
>
>    /Volumes/sandbox/llvm/Debug/bin/clang -x objective-c -arch x86_64  
> -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm- 
> blocks -O0 -Wreturn-type -Wunused-variable -isysroot /Developer/SDKs/ 
> MacOSX10.6.sdk -mfix-and-continue -fobjc-gc -mmacosx-version- 
> min=10.6 -gdwarf-2 -I/Volumes/sandbox/fariborz/radars/BlastApp/build/ 
> BlastApp.build/Debug/BlastApp.build/BlastApp.hmap -F/Volumes/sandbox/ 
> fariborz/radars/BlastApp/build/Debug -I/Volumes/sandbox/fariborz/ 
> radars/BlastApp/build/Debug/include -I/Volumes/sandbox/fariborz/ 
> radars/BlastApp/build/BlastApp.build/Debug/BlastApp.build/ 
> DerivedSources/x86_64 -I/Volumes/sandbox/fariborz/radars/BlastApp/ 
> build/BlastApp.build/Debug/BlastApp.build/DerivedSources -c /Volumes/ 
> sandbox/fariborz/radars/BlastApp/Game.m -o /Volumes/sandbox/fariborz/ 
> radars/BlastApp/build/BlastApp.build/Debug/BlastApp.build/Objects- 
> normal/x86_64/Game.o
>
> Assertion failed: ((isa<PointerType>(SrcTy) ==  
> isa<PointerType>(DstTy)) && "BitCast cannot cast pointer to non- 
> pointer and vice versa"), function getBitCast, file Constants.cpp,  
> line 2231.
> 0   clang-cc          0x00f20b9b PrintStackTrace(void*) + 45
> 1   clang-cc          0x00f2110d SignalHandler(int) + 351
> 2   libSystem.B.dylib 0x90edeadb _sigtramp + 43
> 3   libSystem.B.dylib 0xffffffff _sigtramp + 1863456079
> 4   libSystem.B.dylib 0x90f6f7cf raise + 26
> 5   libSystem.B.dylib 0x90f85bcc abort + 93
>

Hey Fariborz,

Some good news...BlastApp builds clean for me on Leopard (no asserts/ 
errors:-)

I don't have my SnowLeopard machine handy at the moment. I will try  
this later.

If you have a Leopard machine handy, can you verify it builds clean  
for you?

Thanks,

snaroff

> - Fariborz
>