This updates all our text parsers and serializers to better handle tag-delimited fields under editions. Under proto2, groups were the only tag-delimited fields possible, and the group name (i.e. the message type) was guaranteed to be unique. Text-format and various generators used this instead of the synthetic field name (lower-cased group name) to represent these fields.
Under editions, we've removed group syntax and allowed any message field to be tag-delimited. This breaks those cases when adding new tag-delimited fields where the message type might not be unique or correspond to the field name. Code generators have already been fixed to treat "group-like" fields using the old behavior, and treat new fields like any other sub-message.
This change addresses the text-format issue. Text parsers will accept *either* the type or field name for "group-like" fields, and only the field name for every other message field. Text serializers will continue to emit the message name for "group-like" fields, but also use the field name for everything else.
This creates some awkward capitalization behavior for fields that happen to *look* like proto2 groups, but it won't lead to any conflicts or invalid encodings. A feature will likely be added to edition 2024 to allow for migration off this legacy behavior.
PiperOrigin-RevId: 622260327
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
This also fixes maven to package this correctly as google/protobuf/java_features.proto (same dir as WKT/descriptor.proto) instead of com/google/protobuf/java_features.proto.
Fixes https://github.com/protocolbuffers/protobuf/issues/16155
PiperOrigin-RevId: 619015714
Ensures isOptional() does not return true for LEGACY_REQUIRED fields which would otherwise get the optional label applied by default (non-optional fields still get the optional label).
Adds validation to feature resolution instead of cross link, which is too early to have FieldPresence.LEGACY_REQUIRED resolved.
PiperOrigin-RevId: 618857590
Features are designed as temporary migration tools, and any unbounded type leaves the system open to unexpected use. Features should have a fixed set of values, with well defined behaviors.
PiperOrigin-RevId: 617933544
This should fix InvalidWireTypeException in the case of getLiteType() not treating messages with delimited encoding as groups: http://shortn/_2TEPuwIj6P
getJavaType() and needsUtf8Check() changes are no-ops since the type is the same regardless, but these are updated for consistency.
PiperOrigin-RevId: 612972996
Avoid potential races with other threads reading features that do not share a lock while features are temporarily null.
Special handling for proto1 mutable should not actually be needed, since setProto doesn't update dependency protos.
PiperOrigin-RevId: 610783483
JUnit4 does not support nested tests so these weren't running. Fixes setup problems and test logic. Oneof fields now inherit from their oneof, and top-level extensions inherit from top-level file when parent descriptor is null.
PiperOrigin-RevId: 609840087
This fixes an edge-case where EnumDescriptor for a custom option may be unresolved if used in the same file, since adding the field to ExtensionRegistry doesn't trigger its static init block if the Enum is imported from a dependency.
Also renames feature resolution methods exposed from gencode. Private resolveAllFeaturesInternal() method may be renamed back to resolveAllFeatures() in a followup change.
PiperOrigin-RevId: 603852391
GeneratedMessage, not GeneratedMessageV3.
Please rerun protoc on your .proto files to regenerate the binding code.
https://protobuf.dev/news/2023-12-05/https://protobuf.dev/support/cross-version-runtime-guarantee/
To fix source compatibility with surrounding code make these replacements:
GeneratedMessageV3 --> GeneratedMessage
SingleFieldBuilderV3 --> SingleFieldBuilder
RepeatedFieldBuilderV3 --> RepeatedFieldBuilder
PiperOrigin-RevId: 597642289
Editions should not be used to make semantic decisions -- specific helpers (e.g. FieldDescriptor.hasPresence()) should be used instead. FileDescriptorProto can be used to access editions for *non semantic* purposes, incl. with ProtoFileUti.
These APIs have not been released yet and are thus non-breaking.
PiperOrigin-RevId: 597362543
Mike Kruskal
Protobuf Team Bot
Sandy Zhang
Liam Miller-Cushon
Sam Gammon
aiuto
Jiri Pechanec
Luke Sandberg
Chris Kennelly
lowasser
Dennis Shao