Putting it into BUILD files unintentionally forces it on all our downstream users. Instead, we just want to enable this during testing and let them choose for themselves in their builds.
Note, that this expands the scope of -Werror to our entire repo for CI, so a bunch of fixes and opt-outs had to be applied to get this change passing.
Closed#14714
PiperOrigin-RevId: 666903224
If there's an unexpected failure message or an unexpected succeeding test from a wildcard expansion users will be made to remove the wildcarded equivalent. Once removed, they must rerun the conformance test to add the failures contained within the removed wildcarded equivalent.
PiperOrigin-RevId: 663040062
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
Mike Kruskal
Protobuf Team Bot
Adam Cozzette
Yamil Morales
Thomas Van Lenten
Marcel Hlopko
Hong Shin
Brent Shaffer
Eric Salo
Joshua Haberman
Anton Grbin