To allow checked-in and generated versions of the well-known type
generated code to coexist in the repo, we have to give the checked-in
versions a long file path (e.g.
//src/google/protobuf:wkt/google/protobuf/any.pb.cc). However, this path
inadvertently leaked into the generated file_lists.cmake file, so this
commit corrects that problem.
The cc_dist_library() rule originally included only the sources from
direct dependencies. This resulted in a less than ideal developer
experience, because if you ever added a new cc_library() then you would
have to carefully update the necessary cc_dist_library() targets to
ensure that the change was correctly reflected in the CMake build.
This commit addresses that issue by making cc_dist_library() include
transitive sources. We have to be careful to avoid introducing ODR
violations (e.g. from libprotoc duplicating sources from libprotobuf),
so we introduce a new dist_deps attribute on cc_dist_library(). Anything
in dist_deps is assumed to be covered by a separate cc_dist_library()
and is not included. We also make sure to exclude anything that's not
part of our repo (i.e. Abseil and zlib).
This commit adds a staleness test in preparation for setting up
auto-updating of the well-known type generated code. I also went ahead
and updated them manually just to make sure we don't run into any
surprises when this starts happening automatically.
I had to arrange things so that the generated any.pb.cc (for example)
lives at:
//src/google/protobuf:wkt/google/protobuf/any.pb.cc
This is a weird directory structure, but I think it's the only way to
allow the checked-in and generated versions of the file to coexist while
ensuring that Bazel always uses the generated version.
Changes to make this improvement:
1) All non-repeated builder fields (including maps) now have a presence bit regardless of syntax.
2) The buildPartial method is split into one method per 32-field block (aligned with bit-mask ints)
3) If a presence bit-mask int is set to 0, no fields are present, so we can skip the logic for all of those fields in the buildPartial step.
For messages with a lot of fields (> 100) that are sparsely populated this can result in a significant improvement. Not only does it potentially skip a lot of field copying logic, but also breaks the buildPartial method into chunks that should be more easily digested by the JIT compiler as discussed in this issue: https://github.com/protocolbuffers/protobuf/issues/10247.
PiperOrigin-RevId: 485952448
This cl hit an issue during the shared library cmake build from ODR violations, leading to mismatched absl hash seeds. The problem was pre-existing but didn't manifest until now, and can be traced to the fact that in shared library builds we linked Abseil statically. All of the cmake changes here remove the underlying ODR violation.
PiperOrigin-RevId: 485787671
Now that we are syncing all PRs from Piper with Copybara, there isn't a convenient workflow for adding per-language labels to the GitHub PR. (Also even if we required this, Copybara sometimes closes the PR and makes a separate commit, instead of merging the PR).
Long-term we want the release script to bucket by language by automatically detecting which files were modified. In the near-term, the onduty will need to do this manually at release time.
PiperOrigin-RevId: 485730509
- Don't double run the conformance test, let the command line flag be the only
thing that runs it (lower in the script).
- Tweak the arg order to help ensure the script won't invoke with flags in a
different order and impact analysis caching.
PiperOrigin-RevId: 485693911
This is similar to the exemption added to the python generator for gRPC. We don't want to expose these internal implementations in general, but we also don't want to block the adopting of our main branch for existing uses within Google.
PiperOrigin-RevId: 485682767
Jie Luo
Joshua Haberman
Mike Kruskal
Adam Cozzette
Protobuf Team Bot
Copybara-Service
Protobuf Team Bot
Matt Kulukundis
Joshua Haberman
Gregory P. Smith
Chris Kennelly