This doesn't flip the default bazel version, but instead makes this repo
compatible with the current version and bazel 9.x. The primary changes
for 9.x support are adding new load statements for things that were
previously built in. This cascaded into a few dep updates to pull in
their missing load statement fixes.
Closes#26201
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/26201 from keith:ks/add-support-for-bazel-9.x e8192d86b3c838f6c88d4a4adfebd07162debc0d
PiperOrigin-RevId: 878654773
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
After this CL, fasttable functions always take `upb_DecodeFastNext` as a parameter, instead of having some functions return it.
This helps functions compose more easily, since all functions follow the same calling convention.
Also simplified and normalized the set of `upb_DecodeFastNext` values.
PiperOrigin-RevId: 825705376
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
