* Fix undefined symbol error around SharedCtor()
Apparently, #8532 was incorrect if applied to 3.17.x branch.
3.17.x changed code generation to mark `SharedCtor()` and `SharedDtor()` as inline in .pb.cc.
It looks like we have a compile-time undefined behavior in C++ now. As cppreference.com [says](https://en.cppreference.com/w/cpp/language/inline):
_The definition of an inline function <...> must be reachable in the translation unit where it is accessed (not necessarily before the point of access)._
As protobuf allows custom plugins to generate custom code, there is no limitation on where SharedCtor couble be possible referenced from. In our case we have SharedCtor invoked from corresponding `.pb.h` code, thus triggering:
```
ld: error: undefined symbol: package::Message::SharedCtor()`
>>> referenced by file.pb.h:$$$$
```
If this patch is not applicable, I can take a look into changing the code generation, but doing this will be harder then removing _inline_.
* Regenerate checked-in generated .pb.cc files
In an earlier change I moved field_access_listener.cc from the lite
runtime to the full runtime in the CMake configuration, but this caused
//:build_files_updated_unittest to start failing because it expects all
three build systems to be consistent. To fix that, I updated the
Automake configuration and then ran ./update_file_lists.sh to propagate
that change to the other configs.
This reverts commit ca3674b7d5.
While there are savings, it ends up being to easy/common to run into issues with
AppStore validation since the selector usage now appears to be a possible match
for private apis vs. for selectors/properties in the generated code.
* Remove deprecated version of SetTotalBytesLimit()
It has been depcated for at least 3 years.
Worst (backward incompatible) things happened during this period.
I think this method could be safely removed, as the client code fix is trivial.
* Fix coded_stream_unittest.cc
* fix#7074 Safely handle setlocale
`setlocale` returns a pointer to a buffer containing the current locale name.
This needs to be copied into a `std::string` or it will be overwritten by the next call.
Trying to call `setlocale` with a non-null, invalid pointer can have unpredictable results, such as
```
[ RUN ] StringPrintfTest.Multibyte
minkernel\crts\ucrt\src\appcrt\convert\mbstowcs.cpp(246) : Assertion failed: (pwcs == nullptr && sizeInWords == 0) || (pwcs != nullptr && sizeInWords > 0)
```
`setlocale` can also return a `nullptr` if it fails, but we assert against that.
* stringprintf_unittest.cc: Replace `new char[n+1]` with `std::array`
Prefer safer alternative to naked pointers.
This is a follow-up to 1dd313cd0611ac13257c075a977d46c874c42652
- Accept "-" as the expected prefixes file and turn off all validations of
prefixes (even the Apple conventions).
- Reflow some of the prefix checks to hopefully make things a little easier
to follow.
- Don't print warnings about updates to the expected prefix file until there is
a file.
This likely should have been the default from the start, as without it is way to
common to get symbol collisions between different proto files. It would be nice
to support a "migration" mode where both names are created to aid it moving code
to this model, but with ObjC `@class` decls being very common to avoid header
imports to control rebuilds/etc., it doesn't work as an `@class` usage will
error if one also uses `@compatibility_alias`. Falling back to `#define` the two
together also doesn't work as the header with the `@class` will cause methods to
get defined with one interface, but when methods taking those types are define
will likely #import the generate header and thus get the define and end up with
a different signature. So for now, there is no migration support and code has to
be updated in one shot with enable the new prefixing.
- Add a generation option to enable this change in generation.
- Add a second generation option to provide a list of proto package that are
exceptions from using the proto package. This allows easier
migration/updating of code one package at a time.
Adds an option to protoc `--objc_opt=elide_message_metadata` to remove all the property
metadata from message classes. This significantly reduces the codegen size of the clases.
The downside is that iterating through properties using objective c runtime calls will no
longer function. This is mitigated by the fact that most (all?) of the information that
folks are interested in can be extracted via the message descriptor.
We do this by defining our own classes using the `GPB_MESSAGE_SUBCLASS_IMPL` macro.
