Create/Collect all the MessageGenerators/EnumGenerators/ExtensionGeneators up at
the FileGenerator level and remove the need for some helpers and need for
generation apis to recurse through the generators.
The only change to the .pbobjc.m files is positionally where the enum support
for nested enums appears, it now is the same order as it was in the .pbobjc.h
files instead of being closer the the type it was nested in.
PiperOrigin-RevId: 491343515
Prior to the CL we cannot use the printer as that would trigger a recursion. So the only way out would be to create a new printer that has the same abilities as the current printer.
PiperOrigin-RevId: 489024852
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