The static analyzer in some versions of Xcode now flag the enumDescriptor_ as
retained by the generated methods and not being release in dealloc. So avoid the
whole issue by just bringing back the explicit getter.
PiperOrigin-RevId: 488436139
Going back to the first ObjC support commit, there never really was support for
not have the EnumDescriptors, so start removing that partial support.
PiperOrigin-RevId: 488381501
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
--
cc1f708d75 by Joey Parrish <joeyparrish@google.com>:
Fix misdetection of libatomic with strict compiler flags
With strict flags and -Werror, the detection for libatomic breaks, causing it to be included in places where it is not needed. And on macOS, this leads to a link error when libatomic cannot be found.
Closes#10899
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/10900 from joeyparrish:fix-libatomic cc1f708d75
PiperOrigin-RevId: 487859041
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.
Protobuf Team Bot
deannagarcia
Mike Kruskal
Adam Cozzette
Andrii Oriekhov
Joey Parrish
645775992
Jie Luo
Deanna Garcia
Sandy Zhang
Joshua Haberman
Copybara-Service
Protobuf Team Bot