[LLVMdev] type-system-rewrite branch near landing

[Jay Foad]

>> 1. Many Objective-C(++) tests fail, because they use implicitly
>> defined structs for various ObjC runtime data structures; the
>> ASTConsumer HandleTagDeclDefinition callback is never called for these
>> structs, which means that I don't bother to lay them out, so they only
>> ever get an opaque LLVM type. Then we get assertion failures when
>> generating code to access fields in these structs.
>
> Is there some reason we can't just layout types lazily when requested,
> like the old code does?  Should save some work in common cases as well
> as implicitly solve any issues here.

I couldn't get it working that way, but I can't remember exactly what
the problems were. I'll have another go. It would certainly be less
disruptive if it still worked like that.

>> struct S;
>> extern struct T {
>>  struct S (*p)(void);
>> } t;
>> struct S { int i; };
>> void g(void) {
>>  t.p();
>> }

> I don't really like the idea that function types, and especially enum
> types, will permanently be associated with an incomplete type.
> There's too much room for something to screw up, particularly for the
> enum case (which probably won't get tested very well).
>
> I think if you keep track of all the types based on an incomplete tag
> type, and just wipe them all out when the type is completed,
> everything should just work; a type can't be completed in the middle
> of the CodeGen for a function, and we bitcast all globals before use,
> so there's nothing else to change.

So &t would get an LLVM type like {i8*}*; but it would be bitcast to
{%struct.S ()*}* before loading p from it? I'll try that out.

Thanks,
Jay.