protobuf-zig
protobuf-zig copied to clipboard
generated zig code produces dependency loop errors for recursive types
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 https://github.com/ziglang/zig/issues/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.
- [ ] the idea would be to keep
hopefully addressed by https://github.com/ziglang/zig/issues/14517
which is a duplicate of https://github.com/ziglang/zig/issues/131