LabVIEW crashes when generating Client Library

[AstroBuckaroo]

LabVIEW 2019 (32bit and 64bit)

I can't say for sure, but it seems like it is crashing on Create Data Clusters for Types.vi

The screenshot below is for 64bit version. in 32bit it crashes with no error dialog box

AB#2941979

[AstroBuckaroo]

Updated error, this time it didn't crash (as in close) LabVIEW (32bit), instead it showed this error 1060 and stopped the application.

[Niatross]

It appears that this is caused by a circular dependency between two different messages, one side of which is inside of a oneof statement.

A simple example is:

syntax = "proto3";

message parent {

    child childInstance = 2;
}


message child {

    oneof possibilities {
        parent parentInstance = 1;
        string alternative = 2;
    }
}

I am not an expert with gRPC so I am not sure how this is handled in other strictly typed languages. The fact that one side of it is in a oneof statement I can imagine that it is handled by storing the oneof as a variant/equivalent. (I haven't checked this)

The current implementation of oneof puts all possible representations of the element inside the private data of a class. This means that it makes a truly infinite circular dependency.

Fixing this I am assuming will require reimagining the implementation of oneof in this library

[jasonmreding]

For the example above, I suspect it has less to do with the oneof and more about the fact you have recursive type references. In this case, you have a parent message with a field to a child message, and the child message also has a field to the parent message. This is fine in other languages because most other languages have by reference or pointer semantics while LV for the most part only has by value semantics.

For example, in LV, you can't define two cluster types that look like the above. Similarly, in C++/C#, you also wouldn't be able to do this for a struct (value semantic) but you could do it for a class (reference semantic). The compiler would basically give you an overflow error for the value type. This is probably the biggest limitation of grpc-labview at the moment from being feature complete with other languages that support grpc. For something like this to work in LV, we would probably have to generate a class for the field and a DVR (data value reference) around the class when we detect a recursive cycle. This is typically how one would convert a by value class to what is in effect a by reference class. However, the lifetime semantics for the DVR would probably get pretty tricky to manage. Regardless, it would be nice if the code generator was more graceful about detecting this and giving a better error to help the user out.