We recently updated the codebase to comply with the Bazel layering check, which
essentially requires any C++ header inclusion to be matched with a build
dependency on a target providing that header.
As part of that, I removed a handful of dependencies from the `//:protobuf`
target, since these dependencies were not set up in a way that respected the
layering check. However, I realized that this may cause a number of breakages,
especially since we did not provide the correct public targets until very
recently.
This change effectively adds back in the missing dependencies, so that projects
which do not yet adhere to the layering check can continue to depend on them
indirectly. This way, we still adhere to the layering check and make it
possible for projects that depend on us to do so, but in most cases we won't
immediately break anyone.
PiperOrigin-RevId: 607021111
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
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
Co-authored-by: Joshua Haberman <haberman@google.com>
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 #4335
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
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
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 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
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
Co-authored-by: Joshua Haberman <haberman@google.com>
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
CocoaPods fails spec validation for some warnings, so use a local
to avoid warnings for 64->32bit implicit conversions. This comes up
for watchOS builds.
PiperOrigin-RevId: 601849919
Co-authored-by: Thomas Van Lenten <thomasvl@google.com>
There are no restrict calls, so the manifest asserts that.
The CocoaPods support now ensures you are using CocoaPods >= 1.12 as that
avoids all the know bugs in CocoaPods support needed to capture the
Privacy Manifest in a resource bundle.
PiperOrigin-RevId: 602443703
Co-authored-by: Thomas Van Lenten <thomasvl@google.com>
There are no restrict calls, so the manifest asserts that.
The CocoaPods support now ensure you are using CocoaPods >= 1.12 as that
avoids all the know bugs in CocoaPods support needed to capture the
Privacy Manifest in a resource bundle.
PiperOrigin-RevId: 602433417
Co-authored-by: Thomas Van Lenten <thomasvl@google.com>
issue##15029
As required by https://developer.apple.com/support/third-party-SDK-requirements/
Protos does not collect data.
Required reason APIs searched for using:
```
grep -ER 'NSFileCreationDate|NSFileModificationDate|fileModificationDate|NSURLContentModificationDateKey|NSURLCreationDateKey|getattrlist\(|getattrlistbulk\(|fgetattrlist\(|stat\(|fstat\(|fstatat\(|lstat\(|getattrlistat\(|systemUptime\(|mach_absolute_time\(|NSURLVolumeAvailableCapacityKey|NSURLVolumeAvailableCapacityForImportantUsageKey|NSURLVolumeAvailableCapacityForOpportunisticUsageKey|NSURLVolumeTotalCapacityKey|NSFileSystemFreeSize|NSFileSystemSize|statfs\(|statvfs\(|fstatfs\(|fstatvfs\(|getattrlist\(|fgetattrlist\(|getattrlistat\(|activeInputModes|NSUserDefaults' .
```
```
./third_party/utf8_range/utf8_to_utf16/main.c: if (fstat(fd, &stat) == -1) {
./third_party/utf8_range/main.c: if (fstat(fd, &stat) == -1) {
./src/google/protobuf/map.h: s = mach_absolute_time();
./src/google/protobuf/io/io_win32.cc:int stat(const char* path, struct _stat* buffer) {
./src/google/protobuf/io/io_win32.cc: return ::_wstat(wpath.c_str(), buffer);
./src/google/protobuf/io/io_win32.cc: return ::_stat(path, buffer);
./src/google/protobuf/io/io_win32.h:PROTOBUF_EXPORT int stat(const char* path, struct _stat* buffer);
./src/google/protobuf/testing/file.cc: if (lstat(name.c_str(), &stats) != 0) return;
./src/google/protobuf/compiler/importer.cc: ret = stat(std::string(filename).c_str(), &sb);
```
`./third_party/utf8_range/...` - tool for utf that is not in user binaries
`./src/google/protobuf/map.h` - resolved with pull#15554
`./src/google/protobuf/io/io_win32.cc` - windows code
`./src/google/protobuf/testing/file.cc` - testing code not in user binaries
`./src/google/protobuf/compiler/importer.cc` - compiler code not in user binaries
So no required reason APIs.
Apple has not yet communicated how this is to be put into podspecs so saving for future commit.
Closes#15557
It seems possible that old data is stored with serialized descriptors. If we
reject old descriptors due to invalid ctype, the change effectively becomes
breaking changes. We should apply this stricter check for edition 2023 or beyond.
PiperOrigin-RevId: 602516135
Instead of silently ignoring `[ctype = XXX]` for non string or bytes fields,
this CL starts failing to build descriptors to call out the issue. This may
cause failures to existing proto schemas but fixing them should be straightforward.
PiperOrigin-RevId: 602441330
, the initial description:
> For the sake of performance, the hex2bin call was removed from the generated PHP code in https://github.com/protocolbuffers/protobuf/pull/8006
However, after this PR all autogenerated files contain binary data, which makes it hard or even impossible to see using common tools (git and github included (i.e. [this file](https://github.com/protocolbuffers/protobuf/blob/main/php/src/GPBMetadata/Google/Protobuf/Struct.php)), as well as some code editors) since most software considers such files as binary ones and not as code.
Alexander suggested using a hex representation of string literals and I updated the original patch a bit, not hex-encoding printable characters.
Benchmarks from [#10404#issuecomment-1635939062](https://github.com/protocolbuffers/protobuf/pull/10404#issuecomment-1635939062)
```
The percent of printable chars: 0.83869 (80112 vs 15408)
hex parsing: 3.22371, length=382090
hex2Bin parsing: 1.18489, length=191059
hexAscii parsing: 0.89524, length=142306 (suggested option)
binary parsing: 0.26437, length=95542
```
Closes#13911
Also hardened the text format printer against invalid UTF-8 in string fields. The output string will always be valid UTF-8, even if string fields contain invalid UTF-8.
PiperOrigin-RevId: 600990001
zhangskz
Adam Cozzette
Joshua Haberman
Protobuf Team Bot
Protobuf Team Bot
Mike Kruskal
Mikhail Galanin
Jakob Buchgraber
Eric Salo