generated zig code produces dependency loop errors for recursive types

[travisstaloch]

trying to generate code for a simple recursive message type produces the following dependency loop error.

$ script/gen-all.sh -I examples examples/recursive.proto 
zig-out/bin/protoc-zig --zig_out=gen -I examples examples/recursive.proto
zig test gen/recursive.pb.zig --pkg-begin protobuf src/lib.zig --pkg-begin protobuf src/lib.zig --pkg-end -freference-trace
src/google/protobuf/compiler/protobuf-types.zig:144:13: error: dependency loop detected
        pub const descriptor = MessageDescriptor.init(Self);
        ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
referenced by:
    init: src/google/protobuf/compiler/protobuf-types.zig:305:56
    descriptor: src/google/protobuf/compiler/protobuf-types.zig:144:49
    field_descriptors: gen/recursive.pb.zig:64:5

i'm tracking ziglang/zig#12325 hoping it will fix this. i'd rather wait for it than proceed with generating c code and using it cause the c route gets messy very fast. i don't to deal with 3 files per generated .proto nor want users to have to do so.

what is happening here? each generated .proto message type needs to have const descriptor and field_descriptors decls. this is because in deserialize() desc needs a reference to fields here. and later a desc.field needs a reference back to a MessageDescriptor here.

i have considered and played with these workarounds:

• using with -ofmt=c to generate compatible struct defs for types in protobuf-types.zig and here. but it seems -ofmt=c doesn't gen structs decls yet.
• generating c code myself. this is possible now by manually setting gen.zig#output_format = .c. however this means that i have to make sure my zig structs are exactly synced up with c structs. this is a pain to do manually. maybe it could be automated? its easier to just wait for now and see if the issue above fixes it.
  • the idea would be to keep {Field,Message,Enum}Descriptor in a .proto file and generate zig and c code from it.

[travisstaloch]

hopefully addressed by ziglang/zig#14517

[travisstaloch]

which is a duplicate of ziglang/zig#131