Similarly it is doable via the API: create a named struct, create elements where one refers directly to the
newly created struct (instead of pointer), and then setbody.
I can't see how such a type can be useful (I created it by accident, meant to use pointer-to struct,
not struct type directly), and in fact llvm-dis crashes on bitcodes with infinetely recursive struct types.
I'd suggest that such infinetely (mutually-)recursive struct types should be rejected on creation,
at least via an assert.
FWIW llvm-as itself crashes on this:
%s = type { i32, i8, %s }
define void @foo() {
%x = alloca %s
ret void
}
Looks like it is possible to create an infinitely recursive struct type, llvm-as accepts this:
%s = type { i32, i8, %s }
This should be illegal, and should probably be caught by the verifier.
I suppose Edwin would like llvm to check (and let failed) in type
constructing, earlier than verifier.
I guess, such a insane type building might cause in various point,
...to go in an infinite loop or stack overflow.
There is a balance between time and cost of what happens in asserts and the verifier. If it's fast and has good algorithmic complexity, I wouldn't object to it as an assert.