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

[David Chisnall]

On 9 Sep 2008, at 18:00, Daniel Dunbar wrote:

> Hi,
>
> I agree this is a problem, but I'm not sure of the solution yet and
> haven't had time to think about it much.
>
> To clarify the issues:
>
> (1) We need to have predefined types for all of id/Class/SEL/Protocol
> because they occur in the language (self, _cmd, @protocol, etc).

Yup.

> (2) If these types are subsequently defined in headers, then they need
> to bind to the internal types.

Agreed.

> (3) At CodeGen, we need provide actual definitions for these types. In
> theory we could do a lot of bitcasting to avoid this, but that makes  
> very
> ugly IR.

Yes.  The second patch I sent will actually break this with the Étoilé  
runtime, since this uses i32 for SEL (they're just an index in a hash  
table).

> From a design perspective it seems like the predefined types should  
> start
> as opaque types in clang. This I believe solves the original issue  
> David
> presented, but I think it also means a number of changes to Sema. This
> should handle (1) and (2).

Yup.  I would prefer totally opaque types with no assumptions about  
whether they're typedefs, pointers, or whatever.

> For CodeGen, I think we just look and see if the type has been  
> refined. If
> so we make sure it is compatible with the real type. If it hasn't  
> been refined,
> we provide the definition.

This makes sense.  Ideally we should be calling the methods in  
ASTContext from the runtime back ends to get these types, and printing  
some friendly error if they are defined as a type which is not  
structurally equivalent to what the runtime back end expects.

> Is this workable and I am missing things?

I think this is all sensible.

David