This CL adds support for the Edition 2026 custom JSON enum name feature (pb.enumvalue.json) in PHP Protobuf.
Note that we don't need extension caching similar to C++ or Java because our PHP code generator collects custom JSON names at protoc compile time and passes them to DescriptorPool::internalAddGeneratedFile(), populating EnumValueDescriptor and EnumDescriptor during descriptor registration.
Tested with PHP unit tests across pure-PHP and C-extension modes.
PiperOrigin-RevId: 963411589
Fix the GitHub Actions CI failure in
`UpdateReservedTest::testBashScriptIdempotency` introduced by PR #27456.
### Problem:
`update_reserved_words.sh` generated array formatting that differed from
the repository's checked-in files, causing the strict idempotency test
to fail:
1. Column padding used a single global max width across all columns
instead of calculating padding per column.
2. Generated array line lengths in multiple files exceeded 80
characters.
3. Proto test files had slight formatting differences compared to the
script's one-liner output.
### Solution:
- `update_reserved_words.sh`:
* Updated `format_columns()` to calculate padding per-column in pure
Bash, matching standard C/C++ array alignment without requiring
external tools.
* Adjusted array column counts (`names.c` to 4, `php_generator.cc` to
5, `GPBUtil.php` to 3) so lines stay strictly within 80 characters.
- `GPBUtil.php` & proto test files:
* Synced formatting to match the updated script output byte-for-byte.
PiperOrigin-RevId: 963153840
See https://github.com/googleapis/google-cloud-php/issues/9193
`protoc` is generating the invalid class name `Object` when it should be prefixed with `PB` to prevent a conflict with PHP reserved words. I've submitted a fix for this in #27475
This PR introduces the script `php/update_reserved_words.sh` which updates the library in the **8 different classfiles** which all have various ways this logic is defined. Hopefully this makes these things easier for us to maintain in the future.
**NOTE**: prefixing constants with PB has been unnecessary since PHP 7, so we can and should open those up to every word but `class` in the next major version. I've added a comment so we (hopefully) don't forget
```sh
$ bash php/update_reserved_words.sh
Updated src/google/protobuf/compiler/php/names.cc
Updated php/ext/google/protobuf/names.c
Updated src/google/protobuf/compiler/php/php_generator.cc
Updated php/tests/proto/test_reserved_message_lower.proto
Updated php/tests/proto/test_reserved_message_upper.proto
Updated php/tests/proto/test_reserved_enum_lower.proto
Updated php/tests/proto/test_reserved_enum_upper.proto
Updated php/tests/proto/test_reserved_enum_value_lower.proto
Updated php/tests/proto/test_reserved_enum_value_upper.proto
Updated php/tests/GeneratedClassTest.php
Updated php/src/Google/Protobuf/Internal/GPBUtil.php
```
Closes#27456
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/27456 from bshaffer:php-update-reserved-words 522d93f1c1
PiperOrigin-RevId: 962903274
This limit has no public api to override to a different limit: it is only ever set to the 'default' of 32 MB but has actually just not applied at all in many cases.
If we 'fix the bug' by making it so this limit does apply, it would break any users who may be successfully parsing data arbitrarily larger than 32 MB with no issue today due to hitting a case where limit is consistently not applied. By contrast, removing this doesn't formally break any preexisting users, and realigns the behavior to match PHP-upb as well as the default behavior in all of our other supported runtimes.
Note that gRPC-PHP will also already enforce a 4mb limit by default before passing the data to Protobuf, so the only people who could be exposed to this topic either way would need to be either intentionally bumping up the gRPC limit or not using gRPC at all.
In general the need to have a limit within CodedInputStream is very weak in this case compared to other languages: since PHP only parses off of a string and not a stream, it trivial for application code to apply a limit with an if before the parse starts.
PiperOrigin-RevId: 950914431
`'0'` as a key is automatically converted to `0`, so we need to explicitly stringify the keys back to handle that case correctly.
Original issue report from adalogics
PiperOrigin-RevId: 947066825
