[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/
snaroff at apple.com
Sat Jul 11 07:27:10 PDT 2009
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
>> 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/
> 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/
> 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
Some good news...BlastApp builds clean for me on Leopard (no asserts/
I don't have my SnowLeopard machine handy at the moment. I will try
If you have a Leopard machine handy, can you verify it builds clean
> - Fariborz
More information about the cfe-commits