Need Support for Recursively Defined Message Types

[SallyTYT]

grpc-labview now cannot support recursively defined message types , for example, the below message.

https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/descriptor.proto, line 120 - 153

message DescriptorProto {
  ... ...
  repeated DescriptorProto nested_type = 3;
  ... ...
}

When generating code using this proto file, it will report the below error,

I've confirmed in my Python and C++ test environments for gRPC that this recursively defined struct should use pass-by-reference rather than pass-by-value. The latter would result in infinite recursion and memory leaks. LabVIEW typedefs also have the capability to achieve a similar definition using control references, but currently, our toolchain doesn't support this. Could we add support for this feature?

Thank you!
Yongtao Tan

AB#2523253

[sreekantham]

@Rohith-Grandhi, this is blocking development in MeasurementLink as well as we are wanting to include annotations.proto which includes this descriptors.proto. I will reach out to you on directly as well.

[jasonmreding]

In the case of annotations.proto, it would be nice if grpc-labview could just ignore the imports rather than throwing an error. In this case, the annotations are just markup to the proto file, and they don't really impact the generated code at all. Or at least they wouldn't have to impact codegen for grpc-labview since the annotations are usually used as part of reflection APIs utilized by more advanced features provided by web frameworks like ASP.NET Core.

This might be related to another item which I would consider a bug which is grpc-labview shouldn't always produce generated code for .proto files that are imported from other .proto files. Instead, I should have the option to link against a standard package which already includes the generated code. For example, this is how the C# language integration with grpc works. This would probably also require grpc-labview to infer or mandate the generated library name based on the proto package name rather than allowing the user to choose the name. Otherwise, there is no definitive way to generate/define the types since the library name is part of the type name in LV. This would also help minimize coercion dots for common imports/types that are generated as dependencies from multiple proto files.