This is a longstanding feature request from users. By
marking generated code with semantics, we will be able
to filter read calls from write calls.
PiperOrigin-RevId: 487630592
I went ahead and deleted the update_file_list.sh script, because (a)
there was no good reason for it to be in a separate script and (b) we
now need to handle the well-known types in addition to file_lists.cmake.
With this change, we just invoke the staleness tests from the main
script to update everything.
While I was at it I made a couple small fixes:
- Don't skip the update step just because the previous commit was by
"Protobuf Team Bot". Copybara commits use this name and we still want
to do the auto-update step after them.
- Include the CL number in the description if the previous commit came
from a CL.
PiperOrigin-RevId: 487231324
We generate a Kotlin file to correspond to each message, which left the per-file generated file blank. We would still like to generate a file to deal with edge cases where there are no messages defined in a proto file. To fix, we print the default comment about the file being generated as well as a package statement.
PiperOrigin-RevId: 486969373
The Java Any.is() and Any.unpack() methods now accept an exemplar message in
place of a Java class. This avoids the need to use Java introspection in the
implementation of these methods. The exemplar variant of Any.is() is named
Any.isSameTypeAs(). The exemplar variant of Any.unpack() is named Any.unpackSameTypeAs().
PiperOrigin-RevId: 486748727
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