Until recently, these targets were dependencies of `//:protobuf` and could thus
be accessed through that target. But now that we are adhering to the layering
check, we need to provide proper access in a way that respects that check. This
change uses top-level alias targets following the existing pattern.
PiperOrigin-RevId: 605123979
- The comment stated that the option does not affect lite, but this appears to be false: in my testing the option affects both lite and full protos.
- The comment failed to mention that the option has no effect when set explicitly to false. It can only be used to opt proto2 into extra checking, it cannot opt proto3 out of the checks.
PiperOrigin-RevId: 605097398
The replacement always_print_without_presence_fields should be used instead, which is very similar but has consistent handling of optional fields by not affecting them.
PiperOrigin-RevId: 604381178
This fixes an edge-case where EnumDescriptor for a custom option may be unresolved if used in the same file, since adding the field to ExtensionRegistry doesn't trigger its static init block if the Enum is imported from a dependency.
Also renames feature resolution methods exposed from gencode. Private resolveAllFeaturesInternal() method may be renamed back to resolveAllFeatures() in a followup change.
PiperOrigin-RevId: 603852391
Needed to pass in the message as a parameter to the clearer thunk!
Now the clear() augmentations in accessors_test.rs are working as expected.
PiperOrigin-RevId: 603394469
This flag has consistent behavior between proto2 and proto3 optionals (by not including either one), unlike always_print_primitive_fields which does include proto2 optional but excludes proto3 optionals.
always_print_primitive_fields is now deprecated and will be removed in an upcoming release.
PiperOrigin-RevId: 603362526
This disables all checks of json_name for upb and protoc under both proto2 and proto3. This option is deprecated that will be removed in future versions, and is only meant as a temporary solution. This also fixes a latent bug in the calculation of camelcase name in Python/upb.
Fixes#12525
PiperOrigin-RevId: 603158026
for Edition 2023 and beyond.
Since ctype option is visible to all languages than just C++, this CL moves
the ctype validation to DescriptorBuilder for Edition 2023 and beyond. This
may cause failures to proto files that were never built for C++ but still
have the issue. Note that this CL does not affect proto2 or proto3.
PiperOrigin-RevId: 603106684
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
Protobuf Team Bot
Protobuf Team Bot
Marcel Hlopko
Adam Cozzette
Joshua Haberman
Ilya Tokar
Matt Kulukundis
Chris Kennelly
Alyssa Haroldsen
Hong Shin
Sandy Zhang
Mike Kruskal
vyq
Brent Shaffer