These have been moved to subdirectories, and the deleted files were just aliases. The public ones will be removed in a future breaking change.
PiperOrigin-RevId: 691136301
Similar to set_alias for singular submessages, we augment hpb with the ability to add already-allocated messages via the generated function add_alias for repeated messages.
PiperOrigin-RevId: 683269532
As of C23, `va_start` no longer requires a second argument, and ignores it when provided. So, the parameter named `unused` is now...unused.
PiperOrigin-RevId: 683183750
In C23, `false` is now of type `bool`, not `int`. This turned a couple places where `false` was returned instead of `NULL` into errors.
The workaround in upb for Windows's broken NAN macro causes an error in Clang under C23, `cannot compile this static initializer yet`, I believe because `0.0 / 0.0` is not valid in constant-evaluation. This seems like it's probably a legitimate result of C23 standardizing constexpr, although it _could_ be a clang bug. In any case, refine the workaround a bit, to avoid this problem.
I've also reverted the kUpb_FltInfinity/kUpb_Infinity back to their former definitions, as INFINITY wasn't broken by the windows header, only NAN.
PiperOrigin-RevId: 683152452
ListFields uses a slightly different codepath from HasField (both are
implemented in generated_message_reflection.cc), and it would be valuable to
add a test case for ListFields in addition to HasFields when reflection API are
tested.
ListFields is used, for example, in Python textproto serialization as a way to
iterate a message.
ListField behaves slightly differently for normal messages vs. MapEntry
messages. In a map, MapEntry essentially have "explicit presence" and empty
fields are considered present.
PiperOrigin-RevId: 682504379
This PR does the following:
* Special-case descriptor.proto to allow for codegen despite being proto2
* Fix a pre-existing bug that gets exercised now during descriptor builds
* Expand test coverage of conformance tests, and fix pre-existing issues
* Properly hook up gencode to staleness infrastructure for automated regen
Closes#18610
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18610 from protocolbuffers:php-regen 773a1bf01a
PiperOrigin-RevId: 682477438
Protobuf php lib encodes 123_000_000 nano like this: 2000-01-01T00:00:00.**123**Z but then it gets decoded into 123 nanoseconds instead of 123_000_000.
There were issue opened some time ago that also describes this behaviour #4335Closes#12396
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12396 from kindratmakc:bugfix/inconsistent-timestamp-json-encode-decode df47c96567
PiperOrigin-RevId: 603118615
addresses https://github.com/protocolbuffers/protobuf/issues/12714 by dumping more concise debug info for protobuf messages and repeated fields via the `serializeToJsonString` function. Additionally, message types which serialize into something other than an array (e.g. `Google\Protobuf\Value`, `Google\Protobuf\Timestamp`, etc) are handled in a special way to make their output consistent with other messages.
```php
$m = new Google\Protobuf\DoubleValue();
$m->setValue(1.5);
var_dump($m);
```
will output
```
object(Google\Protobuf\DoubleValue)#12 (1) {
["value"]=>
float(1.5)
}
```
Closes#12718
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12718 from bshaffer:php-add-debuginfo c40a6f91de
PiperOrigin-RevId: 574115431
Change the pack/unpack format codes 'f' -> 'g' and 'd' -> 'e' which ensure little endian format is used on the wire regardless of machine endianness. This allows the php composer and conformance tests to pass on big endian platforms and should not change any behavior on little endian platforms.
According to the PHP documentation, 'g' and 'e' were added in PHP versions 7.0.15 and 7.1.1.
Closes#13444
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13444 from linux-on-ibm-z:php-endian-fix 7840e09755
PiperOrigin-RevId: 553954880