Bazel 8 no longer supports legacy toolchains, so all of our release toolchains have been updated to use platforms.
#test-continuous
PiperOrigin-RevId: 870017275
This docker image includes ruby gems v4.0.5, which includes https://github.com/ruby/rubygems/pull/9245 that fixes building multiple native extensions.
PiperOrigin-RevId: 863399053
Theoretically, I think this would've edit our release for -RCs from prerelease to release but we didn't hit this for v34.0-rc1 since the release was set to immutable.
PiperOrigin-RevId: 859735492
38927bf2b9 cleaned up the constinit suppressions based on our understanding of the Windows/MSVC limitations at the time. It turns out this was incomplete and, by restoring constinit on static library MSVC builds, we broke something.
On MSVC, but not clang-cl, the workaround must extend to static library builds too. Although pointers to same-dll symbols are fine and MSVC, with optimizations, will avoid a static initializer, it doesn't seem to consistently recognize it in the type systems, so we can't enforce constinit. See https://godbolt.org/z/cYeYaaWq5
On MSVC, but not clang-cl, the above workaround must extend to static library builds too. MSVC can avoid a global constructor when initializing structures containing pointers to same-dll symbols, it relies on the optimizer for this, so we can't enforce constinit. This limitation does not apply to constexpr. See https://godbolt.org/z/hsT9e3zs4
Add a Windows Bazel C++20 build configuration, which would have caught this.
PiperOrigin-RevId: 858801389
The `publish-to-bcr` workflow now sets `draft: false` when creating the pull request in the Bazel Central Registry fork. This ensures the PR is immediately ready for review.
PiperOrigin-RevId: 855330394
The pyi generator now includes Kythe annotations for:
* Extension field constants (e.g., `EXTENSION_FIELD`).
* Field number constants (e.g., `STRING_FIELD_FIELD_NUMBER`).
* `Create` methods in generated Stubby client classes.
These annotations allow the Python indexer to link these generated symbols back to their definitions in the `.proto` files.
PiperOrigin-RevId: 852971617
#test-continuous
This locks new non-hermetic versions of dependencies that don't work. In this case, webmozart/assert was upgraded from 1.12.1 to 2.0.0
PiperOrigin-RevId: 848269028
Upstreamed from my https://github.com/aspect-build/toolchains_protoc which provided this feature outside the protobuf repo.
Adds:
- private API: module_extension + tag `protoc.prebuilt_toolchain` to provide and register toolchain for bzlmod users
- WORKSPACE users can live with the inconvenience of having to create toolchains themselves
- example of proto_library rule with intentionally non-functional cc toolchain, exercising the feature
This needs work with @thesayyn to:
- constrain users to choosing a protoc version agreeing with design doc
https://docs.google.com/document/d/16N-eU-0zHbWmxEuaUAIFTJwQLekIXZ8zIC3K4XDr20E/edit
- also register lang toolchains when the flag is enabled
Work towards #19558Closes#24115
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/24115 from protocolbuffers:alexeagle/use_prebuilt_toolchain b18667d82c
PiperOrigin-RevId: 844859103
#test-continuous
This behaves similarly to the generated extension registry in other languages. A global ref-counted (lock-free thread-safe) singleton registry can be lazily constructed from the linker array data produced by gencode. For now, this is simply used to preserve custom options on the descriptors in our DefPool.
This design makes heavy use of various non-standard C extensions. It expands on the pre-existing linker arrays used for extensions, adding weak constructors to register all of the extensions linked into each binary. This was tested and works with clang and gcc, and a similar approach was implemented for MSVC. For unsupported compilers or architectures, the generated registry will be unpopulated.
PiperOrigin-RevId: 829698259
Avoids mutating the protobuf tar.gz file that's created prior to the Bazel Central Registry publishing step.
Closes#24065
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/24065 from protocolbuffers:alexeagle/bazel-tar c7df27ec9f
PiperOrigin-RevId: 821727519
Looks like this is really meant to exempt that label from the action. Try this out in case this also includes exempting the *removal* of that label from counting as a unstaleness event. This shouldn't hurt since github bot removes the tag after tests run anyways.
Example: https://github.com/protocolbuffers/protobuf/pull/23994
Documentation: https://github.com/actions/stale
PiperOrigin-RevId: 820319199
These are by far our slowest tests due to their QEMU use. They rarely catch unique issues, so we can handle this in post-submits instead of paying ~4 minutes on every presubmit
PiperOrigin-RevId: 818873557
This build has become a severe bottleneck in our CI. To avoid this in the future, always use whatever pre-install version is on the mac runners. The linux tests will cover specific versions of PHP still.
PiperOrigin-RevId: 818864695
