[cfe-dev] Small change to ObjC builtin type definition
snaroff at apple.com
Tue Sep 9 07:44:20 PDT 2008
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?).
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.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
More information about the cfe-dev