A public "raw" field in a safe wrapper is guaranteed unsound!
This makes repeated and map inner access consistent and
avoids exposing raw internals.
It also provides the accessors necessary for implementing map
access for external types.
PiperOrigin-RevId: 604405543
The replacement always_print_without_presence_fields should be used instead, which is very similar but has consistent handling of optional fields by not affecting them.
PiperOrigin-RevId: 604381178
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
The old flag accidentally had inconsistent behavior between proto2 optional and proto3 optional fields, the new flag treats them consistently (and is consistent with the preexisting behavior of the Go JSON serializer).
includingDefaultValueFields is now deprecated and will be removed in an upcoming release.
PiperOrigin-RevId: 603449195
Needed to pass in the message as a parameter to the clearer thunk!
Now the clear() augmentations in accessors_test.rs are working as expected.
PiperOrigin-RevId: 603394469
This flag has consistent behavior between proto2 and proto3 optionals (by not including either one), unlike always_print_primitive_fields which does include proto2 optional but excludes proto3 optionals.
always_print_primitive_fields is now deprecated and will be removed in an upcoming release.
PiperOrigin-RevId: 603362526
This copy of `setup.py` is obsolete, as it builds the old C++ backend for Protobuf, which has been deprecated and
unused since 4.21.0 when
[the backend was switch to upb](https://protobuf.dev/news/2022-05-06/#python-updates).
The `setup.py` that we actually distribute in our source packages is located in [`python/dist/setup.py`](https://github.com/protocolbuffers/protobuf/blob/main/python/dist/setup.py). It is not possible to build this `setup.py` directly from the GitHub repo or GitHub release tarball, because it depends on the file layout of our Python source package ([as distributed on PyPI](https://pypi.org/project/protobuf/#files)). The Python source package uses a layout that pulls together all of the things Python needs:
|Python Source Package Path|GitHub Repo Path|Description|
|-----|-----|-----|
|`setup.py`|`python/dist/setup.py`|
|`google/protobuf/*`|`python/google/protobuf/*`|pure Python sources|
|`python/*`|`python/*`|C extension sources|
|`utf8_range/*`|`third_party/utf8_range`|C UTF-8 Validation Library|
|`upb/*`|`upb/upb/*`|C Protobuf Library|
Users who want to build their own Python packages should build from our source package on PyPI, not from our GitHub repo or our GitHub release tarball.
It is also possible to build our source package from GitHub using the following command (this requires Bazel):
```
$ bazel build //python/dist:source_wheel
```
PiperOrigin-RevId: 603162788
This disables all checks of json_name for upb and protoc under both proto2 and proto3. This option is deprecated that will be removed in future versions, and is only meant as a temporary solution. This also fixes a latent bug in the calculation of camelcase name in Python/upb.
Fixes#12525
PiperOrigin-RevId: 603158026
This flag has consistent behavior between proto2 and proto3 optionals (by not including either one), unlike including_default_value_fields which does include proto2 optional but excludes proto3 optionals.
including_default_value_fields is now deprecated and will be removed in an upcoming release.
PiperOrigin-RevId: 603156447
The previous limit of 127 was causing error messages to get truncated when long identifiers are in use.
This will increase the stack usage of any code that is allocating a `upb_Status` on the stack. If we want to support smaller stacks in the future, we could change `upb_Status` to store its capacity inline, so different users can allocate error buffers with different capacity.
Fixes: https://github.com/protocolbuffers/protobuf/issues/14376
PiperOrigin-RevId: 603136385
Protobuf php lib encodes 123_000_000 nano like this: 2000-01-01T00:00:00.**123**Z but then it gets decoded into 123 nanoseconds instead of 123_000_000.
There were issue opened some time ago that also describes this behaviour #4335Closes#12396
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12396 from kindratmakc:bugfix/inconsistent-timestamp-json-encode-decode df47c96567
PiperOrigin-RevId: 603118615
Bernard Normier
Chris Kennelly
Alyssa Haroldsen
Protobuf Team Bot
Hong Shin
Adam Cozzette
Jakob Buchgraber
Protobuf Team Bot
Saša Stamenković
Sandy Zhang
Joshua Haberman
Mike Kruskal
lowasser
Masaaki Goshima
Eric Salo
kindratmakc