Refactor many operations to move the split section handing into an out-of-line function. This makes the main function leaner. It includes destruction, merging, clearing, and byte size calculation.
Change serialization to skip split fields by checking first on the default
check. It can skip sequential fields in a single check.
Change merging algorithm to only "prepare" the split section if we need to write to it. Previously it was preparing it if the source had a split section. This is suboptimal because the source might have allocated a split section but not using it anymore (for example, after a `Clear()`).
Changed copy constructor to invoke the out-of-line merger logic for split fields.
PiperOrigin-RevId: 933816045
(We also have some existing test coverage already in
descriptor_unittest.cc but these other edition-specific tests seem to be
missing edition 2024.)
PiperOrigin-RevId: 902261564
In the future this option will be used by the field generators to decide which interface to generate for each repeated field, either proxy or legacy.
PiperOrigin-RevId: 879936002
This doesn't flip the default bazel version, but instead makes this repo
compatible with the current version and bazel 9.x. The primary changes
for 9.x support are adding new load statements for things that were
previously built in. This cascaded into a few dep updates to pull in
their missing load statement fixes.
Closes#26201
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/26201 from keith:ks/add-support-for-bazel-9.x e8192d86b3c838f6c88d4a4adfebd07162debc0d
PiperOrigin-RevId: 878654773
These diffs are non-functional, but generally affected by editions transformations. The naming style feature is perfect for locking this down since it applies to every type of descriptor.
PiperOrigin-RevId: 861207246
We are absorbing its contents into other directories. This will reduce the 3:1 merge to `upb/bazel` in GitHub to 2:1 (soon to be 1:1).
PiperOrigin-RevId: 860299666
As of today:
- GoProto and C# serialize google.protobuf.Empty-packed-into-Any with the `"value":{}` field set
- Only Go, C# and Swift accept that shape at parse time
In an attempt to make spec match reality, the public ProtoJSON documentation has now been clarified to match the common behavior that nearly all implementations have in practice.
Note that this conformance test added is only mandating that implementations:
1) Accept it without the `"value":{}` set
2) Serialize it without it set (by virtue of the round trip coming back to C++Proto in the test harness which does not accept it).
A test that confirms an implementation affirmatively rejects if the "value":{} is set is not added here; especially in the near term it is sensible for implementations like Go and C# to locally continue to accept that shape for backwards compatibility reasons within the same language, as long as it emits without it by default so that other languages can parse what it emits. For that reason, a test affirming a parse failure when it is present is not added to the conformance test suite failure today.
https://github.com/protocolbuffers/protobuf/issues/24445
PiperOrigin-RevId: 854155587
This covers two types of failures:
* Methods that are logically const and failure to consume the result indicates a bug
(an unnecessary call, etc.)
* Methods that return significant errors (failure to parse, etc.) that should not be
unintentionally ignored.
PiperOrigin-RevId: 852313694
All changes to generated code are protected by `PROTOBUF_INTERNAL_REMOVE_ARENA_PTRS_REPEATED_PTR_FIELD`.
With this change, code will now compile with `PROTOBUF_INTERNAL_REMOVE_ARENA_PTRS_REPEATED_PTR_FIELD` enabled.
This change is a no-op and does not enable the change. All generated code is annotated with both the current behavior and the new behavior, and defining PROTOBUF_INTERNAL_REMOVE_ARENA_PTRS will turn the feature on (with no change to codegen needed).
PiperOrigin-RevId: 817848228
This handles all of the global java option changes, as well as the mutable/proto1 features. These can't be reasonably separated because they're all so interdependent.
PiperOrigin-RevId: 808602378
This only needs to handle the `api_level` feature, which has its default flipped in 2024. Preserve the edition 2023 default of using the open API when unset. The `go_api_flag` option is no longer valid in edition 2024, so we migrate to `api_level` unconditionally as well.
PiperOrigin-RevId: 805059796
This overrides `enum_name_uses_string_view` and `string_type` to the 2023 default (when applicable), and migrates ctype->string_type.
PiperOrigin-RevId: 805050955
These are just unconditionally set to the 2023 defaults to preserve old behavior. The feature janitor can clean up in the second pass to minimize diffs when they aren't necessary.
PiperOrigin-RevId: 804615704
Only the features related tests within protobuf need to use a head
version of protoc so they can test changes to feature resolution.
PiperOrigin-RevId: 788049631
While there is support for base64, it requires a runtime cost to decode
back into the bytes, so adding support to write out either hex or decimal
byte values to the encoding. This allows the values to be directly used for
datatypes that are more "byte buffer" than a "string".
Also make the rule's implementation return the output file via the default file
provider.
PiperOrigin-RevId: 786338818
