[cfe-dev] Fix for PR4701

[steve naroff]

On Aug 14, 2009, at 5:21 PM, David Chisnall wrote:

> Hi Steve,
>
> there's a test case attached to PR4701 (http://llvm.org/bugs/show_bug.cgi?id=4701 
> ).  I've just discovered that this still breaks assigning Class  
> variables to struct objc_class* variables and vice versa.  I think I  
> can fix this by adding another hack in  
> Sema::CheckPointerTypesForAssignment(), but I'd still prefer a  
> better approach if you can suggest one...
>

Why not replace 'ObjCIsaExpr' with 'ObjCBuiltinFieldExpr' (used for  
both 'id' and 'Class'...)? You would need to add an explicit  
'IdentifierInfo' slot...

Would this do the trick?

snaroff

> When I try to compile GNUstep, I discover a more subtle problem  
> which my patch now fixes, which is that MetaClass is defined like  
> this:
>
> typedef struct objc_class *MetaClass;
>
> This means that clang fails to notice that MetaClass and Class  
> (which are both typedefs for the same underlying type) are  
> compatible when using the builtin definition of Class, which breaks  
> any assignment of a MetaClass value to a Class-typed variable and  
> vice versa.
>
> David
>
> On 14 Aug 2009, at 22:08, steve naroff wrote:
>
>> Hi David,
>>
>> If you can include a test case that demonstrate what this patch  
>> fixes, I believe I can give you a better approach...
>>
>> Thanks,
>>
>> snaroff
>>
>> On Aug 14, 2009, at 4:56 PM, David Chisnall wrote:
>>
>>> Hi Everyone,
>>>
>>> This patch provides an actual fix (as opposed to my previous  
>>> attempt, which just moved the bugs around) for PR4701, where code  
>>> accessing fields declared on Objective-C pseudo-builtin types id  
>>> and Class broke.
>>>
>>> With this patch applied, all test pass and programs that include  
>>> the GNU runtime's <obj/objc-api.h> compile correctly.
>>>
>>> I am not totally convinced by the approach here.  If a  
>>> redefinition of id or Class is encountered, this is stored any any  
>>> attempt to access a field on one of these builtins is then  
>>> implicitly cast to the real type.  This is quite ugly, but seems  
>>> less ugly than doing it the other way around (adding special cases  
>>> to all of the Objective-C stuff to let struct objc_object* act as  
>>> a receiver, and so on).
>>>
>>> David
>>> <clang.diff>_______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>