Am facing troubles continuing my contribution to an open source and I’II like your help.
Problem:
Am upgrading a library that used the deprecated protobuf to use the new one. If you’ve used the library before you’ll notice the new lib has some of it struct with field that as a
DoNotCopy mutex •[O]sync.Mutex•
The lib am upgrading is not concerned with whether the struct is copied or not… in-fact it does copies it and the logic around the codebase accounts for it but “Go vet” is the problem.
Complains of a copylocks.
The obvious solution Is to pass a pointer to the struct, in the case is in a channel, and doing that would break
function signatures,
type declarations and
interfaces definition
to account for the pointers.
I don’t know if there is a way to suppress or maneuver around this. The “go vet” complaint are always on function arguments or return values, if you’ll need me clarifying more… I’ll be here.
Protobuf messages cannot be trivially copied. This library you’re using might not care about copies (what library is this?), but the protobuf implementation does care. You have to use a function like proto.Clone to pass copies around by value, or else you have to pass a pointer.
I’ve seen the Proto.Clone() and Proto.Merge()…, they seem like viable solutions but my concern is function signatures. If the type am having on a function signature embeds the DoNotCopy type or any type that embeds it, go vet complains. How can i work my way around this?
Dealing with “go vet” copylock complaints can be challenging. Review your code design and use pointers selectively, considering the impact on function signatures and interfaces. It’s crucial to work within Go’s best practices for robust and efficient code.
