Add test cases for Protobuf Editions #225
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Whew! This one is a doozy.
The vast majority of the work is fairly mechanical. In order to test the gauntlet of new semantics that might occur as a result of editions, a new set of test cases are created that mostly mirror the existing tests that already differ between proto2 and proto3. These test cases cover the existing tests that cover edge cases, with the possible set of field presence variants (implicit, explicit, and legacy-required; note that not all of these are valid in all cases) and with both default and expanded repeated field representation.
Most of these changes are transparent or invisible even at the
protoreflect
level and mostly just ensure that protovalidate implementations are not tripping up over the wire format or resulting descriptors.One wrinkle is that getting a new enough version of the protobuf toolchain in Bazel for protobuf editions support is tricky; with upstream rules_proto, the latest toolchain you get does not support editions at all. I ran into a couple of very tricky issues getting a newer toolchain to work, but thankfully the resulting changes to work around those issues are relatively simple:
It seems like the
rules_python
repo needs to be defined for protobuf v27+, but theprotobuf_deps
function does not define it. We must define it ourselves.For unknown reasons, it is necessary to specify both
--proto_compiler
and--proto_toolchain_for_cc
(and presumably other--proto_toolchain_for_*
options). The values specified were actually supposedly the default values for these options, so it is unclear why they need to be specified. I suspect this has something to do with refactoring of Bazel's protobuf rules but didn't want to spend more time investigating, as it took a fair bit of time to figure out that it worked in the first place.