This turns the constexpr constructors into templates to silence errors when constexpr isn't valid. We are also switching to 12.2 for GCC/cmake tests to prevent regressions (9.5 and 13.1 are already tested by GCC/bazel tests).
Fixes#12807
PiperOrigin-RevId: 532258101
Note: gcc only supports docker images down to 9.5, and the 7.3 image is very old and problematic. A follow-up change might enable testing for GCC 7.3, which is our minimal supported version
PiperOrigin-RevId: 529885733
Note: gcc only supports docker images down to 9.5, and the 7.3 image is very old and problematic. A follow-up change might enable testing for GCC 7.3, which is our minimal supported version
PiperOrigin-RevId: 529885733
These more closely follow the standard practices of our users, where dependencies are pre-installed instead of using our provided sub-modules. This will prevent issues such as #12201 from reoccuring.
Additionally, this cl bumps our Abseil dependency to the latest release, and fixes a GTest issue that went previously unnoticed.
PiperOrigin-RevId: 529490402
These more closely follow the standard practices of our users, where dependencies are pre-installed instead of using our provided sub-modules. This will prevent issues such as #12201 from reoccuring.
Additionally, this cl bumps our Abseil dependency to the latest release, and fixes a GTest issue that went previously unnoticed.
PiperOrigin-RevId: 529490402
This is inspired by https://github.com/protocolbuffers/protobuf/issues/12306,
but does not show those failures, so clearly it doesn't catch everything, but
figured some coverage is better than none.
PiperOrigin-RevId: 525134469
Github doesn't currently have Apple Silicon runners, but we can build for
the target to atleast ensure things are building.
PiperOrigin-RevId: 524929865
Github doesn't currently have Apple Silicon runners, but we can build for
the target to atleast ensure things are building.
PiperOrigin-RevId: 524929865
The intent of this change is to take the best ideas from the C++ backend, such as having generator objects that can cache pre-computed state, while minimizing duplication.
Where possible, we take the approach of making the C++ and UPB kernel-specific code as similar as possible, since this reduces the number of templates we need to keep in sync.
PiperOrigin-RevId: 524903073
This turns out to be quite of a yak shave to be able to perfectly test both kernels without having to pass extra Blaze flags.
PiperOrigin-RevId: 521850709
PHP 8.2 is around the corner, and they've just published 8.2.0RC2.
So, what about testing protobuf with it?
Also: even if everything compiles and the PHP extension can be used, we may have that PHP throws some warnings at startup.
For example, if we install protobuf 3.18.3 with PHP 8.1, we have these warnings:
```
$ php -r 'echo "This is just a test.\n";'
Deprecated: Return type of Google\Protobuf\Internal\RepeatedField::offsetExists($index) should either be compatible with ArrayAccess::offsetExists(mixed $offset): bool, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in Unknown on line 0
[...omissis... ]
Deprecated: Return type of Google\Protobuf\Internal\MapFieldIter::rewind() should either be compatible with Iterator::rewind(): void, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in Unknown on line 0
This is just a test.
```
So: what about letting the `php-ext.yml` GitHub Action fail in case we have such startup errors?
Closes#10596
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10596 from mlocati:php-8.2-warnings 6383242b14
PiperOrigin-RevId: 518050302
For legal reasons we unfortunately cannot accept any external contributions to
the well-known type protos, so this change reverts the small number of changes
we have received so far.
PiperOrigin-RevId: 517211904
The internal design is consistent with other <lang>_proto_library rules. rust_proto_library attaches rust_proto_library_aspect on its `deps` attribute. The aspect traverses the dependency, and when it visits proto_library (detected by ProtoInfo provider) it registers 2 actions:
1) to run protoc with Rust backend to emit gencode
2) to compile the gencode using Rustc
Action (2) gets the Rust proto runtime as an input as well.
Coming in a followup is support and test coverage for proto_library.deps.
PiperOrigin-RevId: 514521285
For now, this only covers linux on the two architectures we have testing support for. However, it serves as a good sanity check and can be expanded in the future.
PiperOrigin-RevId: 514449399
For now, this only covers linux on the two architectures we have testing support for. However, it serves as a good sanity check and can be expanded in the future.
PiperOrigin-RevId: 514449399
Mike Kruskal
deannagarcia
Protobuf Team Bot
Deanna Garcia
Mike Kruskal
Tomo Suzuki
Adam Cozzette
Thomas Van Lenten
Miguel Young de la Sota
Romfos
Marcel Hlopko
Jakob Buchgraber
Michele Locati
John Cater