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.
* Make StringPiece constructible from std::string_view
This improves interop with certain string-like data structures, allowing to save extra allocation.
* Check feature-testing macro before use
This fixes a few kinds of warnings:
- inconsistent-missing-override when the overriding site is missing the
override keyword
- unused-function when a function is neither visible nor used
- unused-private-field when a private field exists but is never used
- sign-compare when unsigned ints are compared to signed ints. Not all
of those have been addressed, but this warning isn't enabled by
default.
This fixes#8612.
This resolves issues with GCC and Clang warning (as error) about
attribute in an unallowed location, in particular when used with a
generated file using a dllexport_decl value of [[gnu::visibility]].
The correct ordering is already used in the compiler in
FileGenerator::ForwardDeclarations() for each of classes_, as well
as for other existing local values in pregenerated files. This
change ensures that all usages can compile without issue.
This will cause fields named exactly these names to get `_p` appended to them.
This is being done since the C89/C99/etc specs say these name should be macros,
so in an ObjC context, trying to access the fields would result in runtime
failures for unknown selectors. The only way the fields were usable was to use
KVC or via the descriptor based apis, but if someone hit that they likely would
have reported the general issue also.
The well-known types generate C code into wkt.inc, and this C code was
not testing isset($msg->submsg_field) like the generated code does:
```php
// PHP generated getter: checks isset().
public function getOptions()
{
return isset($this->options) ? $this->options : null;
}
```
```c
// C generated getter, does not check upb_msg_has()
static PHP_METHOD(google_protobuf_Value, getListValue) {
Message* intern = (Message*)Z_OBJ_P(getThis());
const upb_fielddef *f = upb_msgdef_ntofz(intern->desc->msgdef,
"list_value");
zval ret;
Message_get(intern, f, &ret);
RETURN_COPY_VALUE(&ret);
}
```
This led to an error where we wnuld try to get a sub-message field from upb
when it `upb_msg_has(msg, field) == false`, which is an error according to upb.
There are two possible fixes for this bug. A guiding principle is that we want
the generated C code in wkt.inc to have the same behavior as PHP generated
code. Following this principle, the two possible fixes are:
1. Change the code generator for wkt.inc to check upb_msg_has(f) before
calling Message_get(). This would match the isset() check that the
The PHP generated code does, and we would leave the PHP code unchanged.
2. Change Message_get() to itself perform the upb_msg_has(f) check for
sub-message fields. This means that generated code would no longer need
to perform an isset() check, so we would want to remove this check from
the PHP generated code also to avoid a redundant check.
Both of these are reasonable fixes, and it is not immediately obvious which is
better. (1) has the benefit of resolving this case when we are in more
specialized code (a getter function that already knows this is a sub-message
field), and therefore avoids performing the check later in more generic code
that would have to test the type again. On the other hand, the isset() check is
not needed for the pure PHP implementation, as an unset PHP variable will
return `null` anyway. And for the C extension, we'd rather check upb_msg_has()
at the C level instead of PHP.
So this change implements (2). The generated code in wkt.inc remains unchanged,
and the PHP generated code for sub-message fields is changed to remove the
isset() check.