Xcode 14 is warning:
```
warning: Run script build phase 'Script: Check Runtime Stamps' will be run during every build because it does not specify any outputs. To address this warning, either add output dependencies to the script phase, or configure it to run in every build by unchecking "Based on dependency analysis" in the script phase. (in target 'UnitTests' from project 'ProtocolBuffers_OSX')
```
This setting avoids that warning.
PiperOrigin-RevId: 488703116
- FieldDescriptor:
- Add a new flag to mark when the enum on the field is closed (vs open).
- Support computing the state for when generated sources predate the support.
- EnumDescriptor:
- Support passing flags to the descriptor creation, currently closed is the
only new flag.
- Add an isClosed property to expose the state of the enum.
This does NOT update generation yet, allows things to be tested before the
generation support is added.
PiperOrigin-RevId: 488671606
- Streamline the FieldDescriptor loop a little.
- Move some of the init methods from PackagePrivate into the impl file as
nothing outside calls them and it better encapsulates the signature.
PiperOrigin-RevId: 488671041
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
Protobuf Team Bot
Anton Grbin
deannagarcia
Mike Kruskal
Adam Cozzette
Andrii Oriekhov
Joey Parrish
645775992
Jie Luo
Deanna Garcia
Sandy Zhang
Joshua Haberman
Copybara-Service
Protobuf Team Bot