[cfe-dev] Small change to ObjC builtin type definition

[steve naroff]

Hi David,

Commit r55990 implements your patch below.

The "good reason" clang predefines or hard codes id/SEL/Class/Protocol  
is gcc does. My original GCC (or clang) implementation(s) didn't do  
this. Nevertheless, I believe GCC changed this within the past 5 years  
or so (so I changed clang). Off hand, I don't know why they changed  
it. It complicates the dance between the compiler and the headers  
(which is weird). Hacking MergeTypeDefDecl() is unfortunate.

Nevertheless, I don't see how this patch completely solves your  
problem. When the FIXME to verify the underlying types is implemented,  
I don't see how this is going to work. Are you going to hack  
Sema::ActOnTranslationUnitScope() to install different types? (that  
correspond to headers from your runtime?).

Please advise,

snaroff


On Sep 9, 2008, at 7:36 AM, David Chisnall wrote:

> On 9 Sep 2008, at 08:23, Jean-Daniel Dupas wrote:
>
>>
>> Le 9 sept. 08 à 02:23, David Chisnall a écrit :
>>
>>> On 8 Sep 2008, at 18:30, Daniel Dunbar wrote:
>>>
>>>> This causes several failure in the test suite
>>>> (Parser/objc-forcollection-*) if I apply. Can
>>>> you investigate?
>>>
>>> I see.  The problem was that now the new id type is being used, but
>>> ASTContext doesn't recognise it as the ObjC type.  I've tweaked it
>>> to set it in ASTContext and removed the assert()s here that check it
>>> isn't already set.  Note that this will now leak, but I'm not sure
>>> what the best way of fixing this is (can we safely delete the old
>>> version?  Should we lazily create them somewhere if they're
>>> referenced before first use (and if so where)?).
>>>
>>> The attached version passes all of the tests that it was passing
>>> before the patch.
>>
>> I not aware of any objc file that does not include at least an header
>> with the definition of the objc runtime base types (id, SEL, BOOL,  
>> …).
>> Why where these types hard-coded in clang first ?
>
> That was the question I asked last week.  Having received no answer, I
> presumed that there was some good reason.  If there isn't, then we can
> delete them from Sema.cpp and reinstate the asserts.
>
> David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev