These classes are deprecated and will be removed in the next breaking change. Users should update gencode to >= 4.26.x which uses GeneratedMessage instead of GeneratedMessageV3.
Tested with //compatibility:java_conformance_v3.25.0 which builds the runtime against 3.25.0 gencode.
PiperOrigin-RevId: 644136172
In this first stage, we rename the directory from protos_generator to hpb_generator, updating all necessary BUILD files and #includes.
PiperOrigin-RevId: 642600953
There is a special case where message factories can be confused: if a module
written in C++ with pybind11 links against a self-recursive message, and that
message is part of another message loaded from Python, then the confusion
will happen.
Example:
# This one is also linked into the C++ module.
message SelfRecursive {
optional SelfRecursive self_recursive = 1;
}
# This one is used only in Python and not linked.
message OnlyUsedInPython {
optional SelfRecursive self_recursive = 2;
}
The caching through message_factory::RegisterMessageClass then happens on one
instance of the factory, but traversal with the lookup in another.
This occurs in the pure Python and upb implementations that have their own
default descriptor pools (and thus message factory).
Fix this by using the already passed message factory to registering the
message class to cache.
A test accounts for this case to avoid regressions.
PiperOrigin-RevId: 642551744
This will reduce unnecessary resource consumption by cancelling running workflows when new commits are pushed to a PR or workflow dispatch. It does not cancel pushes to main or branches.
Closes#16601
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16601 from sethvargo:sethvargo/actions-concurrency 82fd070dba
PiperOrigin-RevId: 629805311
This will allow them to reuse our bazelrc and remote caching setup. This also silences the non-bzlmod windows test that's hitting the windows path length.
PiperOrigin-RevId: 626390416
We're seeing a high flake rate due to remote cache-misses only on Bazel 7 builds. The key change here seems to be adding the remote_download_output flag, but this also upgrades us to 7.1.1 and adds some retry behavior to caching issues.
PiperOrigin-RevId: 625892332
I'm not sure why exactly but GitHub Actions is complaining about the reference
to `matrix.PLATFORM`. Let's just delete that and the visionos builds until
we're ready to turn visionos back on.
PiperOrigin-RevId: 617922287
This installs a upb's static library, headers, and three protoc plugin binaries (upb, upbdefs, upb_minitable). These will now be enabled by default, but can be disabled by setting protobuf_BUILD_LIBUPB=OFF.
To qualify this, we hook into our existing install test infrastructure which attempts to build and run our tests without any of the installation artifacts available from the source tree. Public headers are deleted, and builds of exported libraries/binaries are disabled.
PiperOrigin-RevId: 617376961
The latest github runner image of ubuntu-22 includes a kernel update that breaks the sanitizers we use in our docker images. Long-term, we'll likely need to upgrade the images to new sanitizers and clang.
PiperOrigin-RevId: 616319042
The Bazel action currently isn't setup to regenerate the proto gencode itself, meaning that it won't actually be running on changes in the pending PR. Long-term, we should migrate this back to Bazel after enabling proto codegen properly.
PiperOrigin-RevId: 611238217
When we get a pull request from outside the protobuf repository, the tests will
not run until a protobuf team member adds the `safe for tests` tag. This change
updates the error message to make it more clear what has to happen to get the
tests to run.
Fixes#15847.
PiperOrigin-RevId: 608660908
This will enable us to get the correct crate names for Rust gencode. The actual
reading of the mapping file in protoc happens in the followup.
PiperOrigin-RevId: 597509582
This check enforces that each C++ build target has the correct dependencies for
all headers that it includes. We have many targets that were not correct with
respect to this check, so I fixed them up.
I also cleaned up the C++ targets related to the well-known types. I created a
cc_proto_library() target for each one and removed the :wkt_cc_protos target,
since this was necessary to satisfy the layering check. I deleted the
//src/google/protobuf:protobuf_nowkt target and deprecated :protobuf_nowkt,
because the distinction between the :protobuf and :protobuf_nowkt targets was
not really correct. Neither one exposed the headers for the well-known types in
a way that was valid with respect to the layering check, and the idea of
bundling all the well-known types together is not idiomatic in Bazel anyway.
This is a breaking change, because the //:protobuf target no longer bundles the
well-known types. From now on they should be accessed through the new
//:*_cc_proto aliases in our top-level package.
I renamed the :port_def target to :port, which simplifies things a bit by
matching our internal name.
The original motivation for this change was that to move utf8_range onto our CI
infrastructure, we needed to make its dependency rules_fuzzing compatible with
Bazel 6. The rules_fuzzing project builds with the layering check, and I found
that the process of upgrading it to Bazel 6 made it take a dependency on
protobuf, which caused it to break due to layering violations. I was able to
work around this, but it would still be nice to comply with the layering check
so that we don't have to worry about this kind of thing in the future.
PiperOrigin-RevId: 595516736
Mike Kruskal
Hong Shin
Jason Lunn
Sandy Zhang
Protobuf Team Bot
Bastien Jacot-Guillarmod
Seth Vargo
Alex Eagle
Adam Cozzette
YoloMao
Thomas Van Lenten
Marcel Hlopko
Eric Salo