[LLVMdev] type-system-rewrite branch near landing

[Eli Friedman]

On Thu, Jul 7, 2011 at 12:55 AM, Jay Foad <jay.foad at gmail.com> wrote:
>> 1. Clang - Jay, do you have a patch for this?
>
> Yes. It's good enough to build most of LLVM+Clang, except for a couple
> of files. But I'm running out of time and expertise to be able to fix
> the remaining bits. Some specific concerns:
>
> 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.

> 2. Even some simple C cases fail, e.g.:
>
> struct S;
> extern struct T {
>  struct S (*p)(void);
> } t;
> struct S { int i; };
> void g(void) {
>  t.p();
> }
>
> The problem here is that T.p is codegenned as i8*, so we need to
> bitcast it to a proper function pointer type before calling it.
> Shouldn't be too hard to implement.

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.

> 3. There are other CodeGen tests that fail with assertion failures,
> which I haven't investigated. (I'm starting to wonder if I went too
> far when I ripped out all the PointersToResolve /
> HandleLateResolvedPointers() stuff from CodeGenTypes.cpp.)

Hmm... there shouldn't be anything you need to handle there, I think.

> 4. A bunch of the CodeGen tests need adjusting because we're
> generating slightly different IR from what they expect.
>
>> Can you create a branch of the clang repo or send an updated version of the patch to the list?
>
> I'd be very surprised if I have the authority to create a branch,
> given things like:
>
>  ~/svn/llvm-project/llvm/branches$ svn up
>  svn: Server sent unexpected return value (403 Forbidden) in response
> to REPORT request for '/svn/llvm-project/!svn/vcc/default'

I think that explicitly returns Forbidden just to avoid the strain on
the server; if you have any write access, you should have write access
to everything.

-Eli