Default to collecting unknown fields as data and then create the
`GPBUnknownFieldSet` on demand when requested.
This should reduce the as the extra objects are created until requested
and clears the way to eventually deprecated `GPBUnknownFieldSet` in the
future.
This also fixes the failing conformance test related to keeping the ordering.
PiperOrigin-RevId: 655929316
This also changes MessageView and MessageMut to be subtraits of the ViewProxy and MutProxy (which also requires them to have lifetimes now, and a weird extra bounds on ViewProxy)
PiperOrigin-RevId: 654788207
`absl::string_view`.
Added temporary macro `PROTOBUF_TEMPORARY_ENABLE_STRING_VIEW_RETURN_TYPE` to turn on the new return type before the breaking change happens. It allows users to test and update their code ahead of time.
PiperOrigin-RevId: 652517294
- In most cases, migrate to `absl::string_view`.
- When capturing a temporary string in a variable, use `const std::string` without the ref.
We avoid changing virtual function parameters in this CL, since that is a breaking change.
PiperOrigin-RevId: 647686085
This was previously fixed in C++ (https://github.com/protocolbuffers/protobuf/issues/16549), but not ported to other languages. Delimited field encoding can be inherited by fields where it's invalid, such as non-messages and maps. In these cases, the encoding should be ignored and length-prefixed should be used.
PiperOrigin-RevId: 642792988
This doesn't _actually_ make the C++ Kernel path ever fail yet, but now that the API is a Result<SerializedData, SerializeError> it can be fixed as an implementation detail.
PiperOrigin-RevId: 638329136
Using https://protobuf.dev/reference/protobuf/textformat-spec
as a guide; add valid suffixes, more cases for special values,
confirm some invalid things do fail.
Also resort the files since some weren't and sorting seems to be required for the
update helper.
PiperOrigin-RevId: 629720194
The only public target here is the edition defaults helper macro, which can be used by external runtimes and plugins. None of this code is C++-specific though, and should be organized higher up. Appropriate aliases are also placed at the top level for public targets
PiperOrigin-RevId: 625392504
Instead of using the message's corresponding field to denote the end of the stream, just abort it on *any* end group tag. If this is an invalid tag, the caller will handle the failure.
PiperOrigin-RevId: 622859234
These are already supported, but this will lock down that there's no issues like the ones we hit with text-format.
This also fixes an unrelated bug in our BinaryToJsonString algorithm related to unknown group handling. We still can't actually test binary->JSON in conformance tests for extensions due to TypeResolver's lack of support though.
PiperOrigin-RevId: 622360970
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
For now, these are limited to tests of text-form for delimited fields that locks down our problematic behavior in editions. Follow up changes will adjust the behavior to behave better under editions.
PiperOrigin-RevId: 622211473
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
Implementations should not rearrange unknown fields for the same field number, because some field types accept multiple wire types (eg. packed and unpacked).
All languages currently pass this test except Java "full" and Obj-C.
PiperOrigin-RevId: 619953711
Three of these runtimes are based on upb, and the fourth is based on the Java runtime. Both of these already have editions support, so this was mostly just a matter of:
- Advertising support to allow editions codegen
- Stripping features from the runtime options
- Hooking up conformance tests
- Adding some lightweight editions tests
There are also a few minor orthogonal fixes included here:
- Ruby's upb hack for treating all enums as open enums needed tweaking
- The `enable_editions` flag is no longer needed in our internal proto rules
PiperOrigin-RevId: 616256211
Until recently, these targets were dependencies of `//:protobuf` and could thus
be accessed through that target. But now that we are adhering to the layering
check, we need to provide proper access in a way that respects that check. This
change uses top-level alias targets following the existing pattern.
PiperOrigin-RevId: 605123979
Thomas Van Lenten
Yamil Morales
Protobuf Team Bot
Mike Kruskal
Marcel Hlopko
Hong Shin
Brent Shaffer
Eric Salo
Joshua Haberman
Anton Grbin
Sandy Zhang
Ryan Govostes
aiuto
Adam Cozzette