Add compatibility with protobuf 28 #541
Conversation
Signed-off-by: Ramir Sultanov <[email protected]>
| auto msgRep = | ||
| google::protobuf::DynamicCastMessage<Rep>(&_msgRep); | ||
|
|
||
| // Verify the dynamically casted messages are valid |
There was a problem hiding this comment.
Does it make sense to move this block of verifications after all the ifdefs? That way we could validate all versions.
There was a problem hiding this comment.
It is me being extra cautious to not break parts of code that already work. After checking the source code of protobuf, I found that google::protobuf::Message::GetDescriptor() and google::protobuf::Descriptor::full_name() functions were in the initial commit. Assuming, they were not removed after that, I think, it is safe to validate messages using the specified block of code. The changes can be found in the corresponding commit.
Signed-off-by: Ramir Sultanov <[email protected]>
|
Currently hitting this issue. Would be great if a backport to transport13 could be considered as well. |
| auto msgRep = | ||
| google::protobuf::DynamicCastMessage<Rep>(&_msgRep); | ||
|
|
||
| // Verify the dynamically casted messages are valid |
|
The homebrew failures are due to osrf/homebrew-simulation#2834 related to Python tests, so I'll go ahead and merge this. |
|
@Mergifyio backport gz-transport13 |
✅ Backports have been created
|
* Add compatibility with protobuf 28 Signed-off-by: Ramir Sultanov <[email protected]> * Add message verification after message down casts Signed-off-by: Ramir Sultanov <[email protected]> --------- Signed-off-by: Ramir Sultanov <[email protected]> (cherry picked from commit 6256a56)
🎉 New feature
Adds compatibility with the Google Protocol Buffers v28.
Summary
Basically, rules for message down casting have been changed in protobuf and this PR modifies the way protobuf is used for downcasting.
Protobuf does not allow to use google::protobuf::internal::DownCast function to downcast message types with concepts enabled in version 28 (see port.h file in this diff). When compiling custom packages which depend on the gz-transport with C++ concepts enabled, there will be compile-time errors, if RepHandler::RunLocalCallback or SubscriptionHandler::RunLocalCallback functions were used (not necessarily used directly, but via some other function, for example: Node::Request).
Alternatively. there are google::protobuf::DynamicCastMessage and google::protobuf::DownCastMessage functions. Because google::protobuf::DynamicCastMessage function has more sanity checks, it was used in this PR with some additional error logging.
Test it
To test the changes you may install the Google Protocol Buffers v28, write some code that uses RepHandler::RunLocalCallback or SubscriptionHandler::RunLocalCallback (not necessarily directly) with C++ concepts enabled, and try to compile the code.
Checklist
codecheckpassed (See contributing)Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining
Signed-off-bymessages.