Our stale file regeneration logic broke with Bazel 6.4.0, and I suspect it was
caused by this change: https://github.com/bazelbuild/bazel/pull/19534 Our logic
assumed that any target with a `CcInfo` provider must have `hdrs` and
`textual_hdrs` attributes, but it seems that this is no longer true for
`cc_proto_library` starting with Bazel 6.4.0. The fix is just to use `getattr`
and treat the item as an empty list if it's missing.
PiperOrigin-RevId: 575473886
setup-gcloud doesn't honor the environment variables set by setup-python, so we need to manually set CLOUDSDK_PYTHON before running it.
PiperOrigin-RevId: 578674246
These tests were right near the threshold for disk space on default runners, and recently got pushed over (~18G). The cheapest large runner has 150G of SSD storage, and won't likely hit this issue again.
PiperOrigin-RevId: 572596499
This has caused repeated issues due to the fact that it checks the entire repo. Most recently, it decided to complain about a typo in a file that hasn't been touched in 5 years.
PiperOrigin-RevId: 540356791
Our automation can't currently update release branches, so we need to enable staleness tests as presubmits to force manual regeneration.
PiperOrigin-RevId: 540094169
- Do some minimal sanity testing on every PR
- Only run the staleness tests on a daily schedule or explicit runs.
- Add 23.x to the checks
PiperOrigin-RevId: 537952151
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
This crash was due to the fact that we were passing `nullptr` as a `const
char*` parameter and relying on that implicitly converting into an empty
`absl::string_view`. `absl::string_view` supports that functionality, but
starting with C++17 its behavior changes since it's just a type alias for
`std::string_view`. `std::string_view` does not have any special conversion for
nullptr and so we were just getting crashes.
PiperOrigin-RevId: 530431663
Warnings in header files can be a problem for consumers that enable `/WX` (or `-Werror`). In this case, using `... & -align` produces a warning (C4146) with MSVC. The fix is to use equivalent expression `... & ~(align - 1)`, which was already used in the same file.
Fixes#12675Closes#12697
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12697 from coryan:fix-msvc-warnings-in-arena-align 835f3b489a
PiperOrigin-RevId: 530137165
On Wndows, `size_t` is 64-bits, and `int` is 32-bits. That makes conversions from `size_t` to `int` potentially lossy, and they generate warnings. In this case an `int` variable was assigned to `size_t` and then passed to functions consuming `int`. Seems simpler to use `auto` and avoid these problems altogether.
Closes#12701
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12701 from coryan:fix-warnings-repeated-field-warnings-in-msvc b1ec34de77
PiperOrigin-RevId: 530134611
When the protobuf libraries have been compiled as shared libraries the users of the library need to add `-DPROTOBUF_USE_DLLS` to their build line. Otherwise some symbols are missing.
Fixes#12699
FWIW, I am not sure this is an ideal fix. It may be better to fix the headers such that no macros change the ABI.
Closes#12700
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12700 from coryan:fix-define-protobuf-use-dlls-in-pkg-config-file 13c792eebd
PiperOrigin-RevId: 530116678
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
This should fix#12374, #12375, and #12450. The `protobuf_PROTOC_EXEC` variable
is not defined, and I think `protobuf::protoc` is what we should be using
instead.
PiperOrigin-RevId: 525591320
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