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
Crate names must not contain '-'. So we replace any '-' by a '_' to form a valid crate name.
Bazel supports many special characters as target names: !%-@^_"#$&'()*-+,;<=>?[]{|}~/. We don't have to support all of them in Protobuf Rust, but '-' seems used widely enough and is a common alternative to '_' in naming.
PiperOrigin-RevId: 602963206
Add convenience _opt for singular message fields.
Users can detect if the message is set or unset, and unwrap via into_inner.
PiperOrigin-RevId: 602749065
This is the final CL (part 4 of 4) in the ProxiedWithPresence chain.
In the past, we had returned Mut directly for the `_mut` accessors.
This was a temporary engagement in order to get the other submsg machinery checked in.
As we prep for the finalization of v0.6, we can finally conform to the rest of the `_mut` getters.
$field$_mut now correctly returns $pb$::FieldEntry<'_, $msg_type$> as a part of this.
All test callsites have been updated to `.or_default` in order to test the mutational pathway as before.
PiperOrigin-RevId: 602739186
The old flag accidentally had inconsistent behavior between proto2 optional and proto3 optional fields, the new flag treats them consistently (and is consistent with the preexisting behavior of the Go JSON serializer).
PiperOrigin-RevId: 602711486
# Motivation
https://github.com/protocolbuffers/protobuf/issues/7392#issuecomment-1884666885
This is for completeness - I am not blocked by this change in any way, so feel free to close the PR or treat is a low priority.
# Changes
Implement JsonIgnoreUnknownParsingTest in C# conformance test runner.
# Tested
Locally with:
```
bazel test //csharp:conformance_test \
--action_env=DOTNET_CLI_TELEMETRY_OPTOUT=1 --test_env=DOTNET_CLI_HOME=~ \
--action_env=DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1
```
Closes#15369
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/15369 from noom:issue-7392/show-csharp-failures 3a652202a0
PiperOrigin-RevId: 602537927
It seems possible that old data is stored with serialized descriptors. If we
reject old descriptors due to invalid ctype, the change effectively becomes
breaking changes. We should apply this stricter check for edition 2023 or beyond.
PiperOrigin-RevId: 602516135
There are no restrict calls, so the manifest asserts that.
The CocoaPods support now ensures you are using CocoaPods >= 1.12 as that
avoids all the know bugs in CocoaPods support needed to capture the
Privacy Manifest in a resource bundle.
PiperOrigin-RevId: 602443703
Instead of silently ignoring `[ctype = XXX]` for non string or bytes fields,
this CL starts failing to build descriptors to call out the issue. This may
cause failures to existing proto schemas but fixing them should be straightforward.
PiperOrigin-RevId: 602441330
There are no restrict calls, so the manifest asserts that.
The CocoaPods support now ensure you are using CocoaPods >= 1.12 as that
avoids all the know bugs in CocoaPods support needed to capture the
Privacy Manifest in a resource bundle.
PiperOrigin-RevId: 602433417
right kind of extension. This way you get a compile time failure instead of a
runtime one.
Other extension accessors already have this kind of SFINAE restrictions.
PiperOrigin-RevId: 602418580
RepeatedPtrField had been updated to handle Add/MergeFrom when holding an abstract type MessageLite, hence ExtentionSet no longer needs to have custom workarounds.
PiperOrigin-RevId: 602381489
CocoaPods fails spec validation for some warnings, so use a local
to avoid warnings for 64->32bit implicit conversions. This comes up
for watchOS builds.
PiperOrigin-RevId: 601849919
* Tell cinterop that the `const char*` parameter in `upb_Decode` is not actually a string.
* Add `kotlin_native_hint` to `upb/wire`.
PiperOrigin-RevId: 601795518
This is done by specifying suffix punctuation to chomp with WithVars.
If we delete the space on line 64 without also doing the rest of this change, the result is that the comma is not emitted at all.
PiperOrigin-RevId: 601516987
Protobuf Team Bot
vyq
Brent Shaffer
Jakob Buchgraber
Protobuf Team Bot
Eric Salo
Mike Kruskal
Hong Shin
Luke Sandberg
Marcel Hlopko
Anton Grbin
Thomas Van Lenten
Éamonn McManus
Sandy Zhang
Alyssa Haroldsen