[cfe-dev] Small change to ObjC builtin type definition
csdavec at swansea.ac.uk
Tue Sep 9 17:08:10 PDT 2008
On 9 Sep 2008, at 18:00, Daniel Dunbar wrote:
> 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).
> (2) If these types are subsequently defined in headers, then they need
> to bind to the internal types.
> (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
> 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
> From a design perspective it seems like the predefined types should
> as opaque types in clang. This I believe solves the original issue
> 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.
More information about the cfe-dev