* `protoc`: Included in zips alongside binary
* Java: Generated classes have been added to the Maven `util` artifact
* Ruby: Generated classes have been added to gems
* CMake: `.proto` files are included in installation
PiperOrigin-RevId: 957382561
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
#test-continuous
These built-in generators are exposed in the protoc binary we release. Using them as libraries would typically be done by someone creating a custom build of protoc mixing our generators with their own. The supported alternative would be to build your generator as a plugin binary, and use it with the normal protoc binary.
PiperOrigin-RevId: 857982672
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 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
We lean heavily on the preprocessor, but we do so in a nice and readable way that allows us to reuse our lists for several purposes:
- To create C `enum`s for each dimension.
- To count the number of possibilities for each dimension.
- To generate a cross-product of all dimension combinations, with a canonical ordering of functions that lets us address functions by index.
- To generate function names for each combination.
Unlike the initial design for fasttable, this scheme lets us generate an array of all fast field parsers, which will allow us to build fasttables at runtime from MiniDescriptors.
While I ran the tests with `--//third_party/upb:fasttable_enabled=True` and found that most of them pass (and none regress compared to HEAD), this code is not currently tested in TAP and we know that the fasttable parser has bugs. Subsequent CLs will fuzz it against the main parser so that we can make it truly robust.
#test-continuous
PiperOrigin-RevId: 755606670
One of the test cases involves observing the lazy loading behavior of the
generated descriptor pool. Since this pool is a global, it can be influenced by
other unrelated tests, and whether the test succeeds or fails depends on the
test ordering. Moving the test into its own binary ensures that it will pass
regardless of test ordering.
Fixes#21431.
PiperOrigin-RevId: 752313710
The main goal of this is to incorporate the minitable generator into our
released protoc binaries so that Rust users don't have to build it from source.
PiperOrigin-RevId: 728785507
This avoids installing every header required by protoc, and only installs the ones we've explicitly marked as public in bazel (and their transitive dependencies).
PiperOrigin-RevId: 709815861
Repeated/map extensions are semantically equivalent to an extension that is not present at all. We had code paths that were treating them differently, which led to incorrect results.
In particular, we were considering `{.repeated_ext = []}` to be different from `{}` when comparing with `upb_Message_IsEqual()`. This change fixes this bug so that they will be considered equivalent.
PiperOrigin-RevId: 702072912
This yields several benefits:
1. The code no longer needs to be bootstrapped (since it no longer depends on upb reflection).
2. The upb code generator no longer depends on libprotobuf at all (except for `code_generator_lite.{h,cc}`, which is just one .cc file and has no deps).
PiperOrigin-RevId: 672280579
