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 the protobuf_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.
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
protoreflectlevel 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_pythonrepo needs to be defined for protobuf v27+, but theprotobuf_depsfunction does not define it. We must define it ourselves.For unknown reasons, it is necessary to specify both
--proto_compilerand--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.