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
The PHPDoc escaping in PHP is aggressive in that it escapes some character sequences that don't need to be escaped (`/*`), and it uses HTML entities to escape others (`*/` and `@`) instead of the recommended PHPDoc escape sequences.
For Example, in [`Google\Api\RoutingParameter`](https://github.com/googleapis/common-protos-php/blob/main/src/Api/RoutingParameter.php#L42):
```
* path_template: "projects/*/{table_location=instances/*}/tables/*"
```
Should be escaped as:
```
* path_template: "projects/{@*}{table_location=instances/*}/tables/*"
```
according to [the PHPDoc guide](https://manual.phpdoc.org/HTMLframesConverter/default/phpDocumentor/tutorial_phpDocumentor.howto.pkg.html#basics.desc):
- For `@`: "if you need an actual "@" in your DocBlock's description parts, you should be careful to either ensure it is not the first character on a line, or else escape it ("\\@") to avoid it being interpreted as a PhpDocumentor tag marker."
- For `*/`: " If you need to use the closing comment "\*/" in a DocBlock, use the special escape sequence "{@*}."
Closes#11208
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/11208 from bshaffer:more-readable-phpdoc-escaping a75f9745ea
PiperOrigin-RevId: 603091642
Generic services have been deprecated for about 14 years. This is technically a
breaking change, but fortunately the `php_generic_services` option appears to
have little or no usage. I could not find any examples of open source code
using it.
PiperOrigin-RevId: 592677762
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
* Manually run brew cleanup and initialize php
* Add debug loggin for visibility
* Allow underscores in php folder name
* Add logging to php tests
* Add tracing
* Only use the latest installation of php
* Bumping Abseil version to latest LTS
* Upgrade PHP build to latest docker image
* Deleting php 7.0 kokoro build now that it's not supported
* Putting old PHP test back
* Fix test cases that exceed PHP_INT_MAX
* Bazelfying conformance tests
Adding infrastructure to "Bazelify" languages other than Java and C++
* Delete benchmarks for languages supported by other repositories
* Bazelfying benchmark tests
* Bazelfying python
Use upb's system python rule instead of branching tensorflow
* Bazelfying Ruby
* Bazelfying C#
* Bazelfying Objective-c
* Bazelfying Kokoro mac builds
* Bazelfying Kokoro linux builds
* Deleting all deprecated files from autotools cleanup
This boils down to Makefile.am and tests.sh and all of their remaining references
* Cleanup after PR reorganizing
- Enable 32 bit tests
- Move conformance tests back
- Use select statements to select alternate runtimes
- Add internal prefixes to proto library macros
* Updating READMEs to use bazel instead of autotools.
* Bazelfying Kokoro release builds
* First round of review fixes
* Second round of review fixes
* Third round of review fixes
* Filtering out conformance tests from Bazel on Windows (b/241484899)
* Add version metadata that was previously scraped from configure.ac
* fixing typo from previous fix
* Adding ruby version tests
* Bumping pinned upb version, and adding tests to python CI
* Updated PHP to the new version of upb.
This is a large change, as the upb API surface has been
renamed to follow Google style more closely.
* Fixed utf8_range.
* Updated Ruby for new utf8_range.
* Picked up new upb for PHP, with spelling fixes.
* Fixed the 32-bit build.
* fix: add missing reserved classnames
* Try to remove PARENT and SELF from reserved constants
* add back for tests
* add to validConstantNames
* update kReservedNamesSize
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.