[LLVMdev] Order of fiels and structure usage

[Hendrik Boom]

I'd like to be able to make use of a structure type and its fields before 
it is completely defined.  To be specific, let me ask detailed questions 
at various stages in the construction of a recursive type.  I copy from 

http://llvm.org/docs/ProgrammersManual.html#TypeResolve

    // Create the initial outer struct
    PATypeHolder StructTy = OpaqueType::get();

Is it possible to declare variables of type StructTy at this point?
Is it possible to define other structured types that have fields of type 
StructTy at this point?  I'm guessing the answers to these questions are 
"Yes".

    std::vector<const Type*> Elts;
    Elts.push_back(PointerType::get(StructTy));

Is it possible to build an expression that uses the newly generated Elt 
as field-selector at this point?  I'm hoping yes, but I suspect No, 
because the elments of Elts* are clearly Type* instead of being a field.  
In particular, if I use the same type twice to make two fields, the 
corresponding elements of Elts will be indistinguishable.

    Elts.push_back(Type::Int32Ty);
    StructType *NewSTy = StructType::get(Elts);

Presumably at this point is is definitely possible to declare variables 
of type NewsTy and use field-selectors from NewSTy.  But it's a little 
too late for my purposes.

The types I'm dealing with are not recursive, but of course I'll have to 
perform the rest of the steps so that the variables I declared long ago 
finally get well-defined types.

// At this point, NewSTy = "{ opaque*, i32 }". Tell VMCore that
// the struct and the opaque type are actually the same.
cast<OpaqueType>(StructTy.get())->refineAbstractTypeTo(NewSTy);

// NewSTy is potentially invalidated, but StructTy (a PATypeHolder) is
// kept up-to-date
NewSTy = cast<StructType>(StructTy.get());

// Add a name for the type to the module symbol table (optional)
MyModule->addTypeName("mylist", NewSTy);


If the answers to my questions are "yes", I can generate code easily for 
all the variations on the source language I'm compiling.  If any are "no" 
I'll be significantly constrained in what I'll be able to do easily 
(i.e., without extra code generation passes and intermediate data 
structures).

-- hendrik