When we build DSOs in CMake, we use the `-fvisibility=hidden` flag to hide
symbols by default and then explicitly export public-facing symbols using
`__attribute__((visibility ("default")))` (for example via the
`PROTOBUF_EXPORT_TEMPLATE_DECLARE` macro).
A bunch of symbols related to `google::protobuf::RepeatedPtrField<std::string>`
were not visible on libprotobuf.so for GCC builds, and it turned out to be
because GCC was ignoring the visibility attribute due to it appearing after
`RepeatedPtrField<std::string>` had already been instantiated.
I tried moving the declaration up in the file, but found that if I move it up
high enough to fix GCC then it breaks Clang. So instead, this change just
disables the code size optimization that required us to centralize the template
definition in one .cc file. Now any usage of `RepeatedPtrField<std::string>`
will be inlined into each translation unit that uses it, so we don't have to
worry about the definition being visible in libprotobuf.so.
Fixes#10833.
PiperOrigin-RevId: 487885077
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
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
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
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
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
Adam Cozzette
Protobuf Team Bot
Mike Kruskal
Deanna Garcia
Protobuf Team Bot
Matt Kulukundis
Chris Kennelly