`google.protobuf.Any` formatting with indentation was somewhat off.
Formatting an `Any` as root object:
```json
{"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
```
changes to
```json
{
"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
```
For messages were `Any` is in a nested field the change makes more of a visual impact.
The `c` field seems to be at the same level as the `anyField`, but it's nested so it should be indented:
```json
{
"anyField": {"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
}
```
changes to:
```json
{
"anyField": {
"@type": "type.googleapis.com/protobuf_unittest3.ForeignMessage",
"c": 1
}
}
```
Closes#16785
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16785 from q42jaap:main 72deed6ed7
PiperOrigin-RevId: 632506226
All of this information is still available by merging fixed_features and overridable_features. This new split will make validation easier for runtimes that need to do dynamic builds.
PiperOrigin-RevId: 625815212
These are already supported, but this will lock down that there's no issues like the ones we hit with text-format.
This also fixes an unrelated bug in our BinaryToJsonString algorithm related to unknown group handling. We still can't actually test binary->JSON in conformance tests for extensions due to TypeResolver's lack of support though.
PiperOrigin-RevId: 622360970
For now, these are limited to tests of text-form for delimited fields that locks down our problematic behavior in editions. Follow up changes will adjust the behavior to behave better under editions.
PiperOrigin-RevId: 622211473
Features are designed as temporary migration tools, and any unbounded type leaves the system open to unexpected use. Features should have a fixed set of values, with well defined behaviors.
PiperOrigin-RevId: 617933544
WriteDictionary does not pass indentationLevel downwards to WriteValue. The existing test for `MapField` only tests `MapField<string, string>`, which isn't affected by the issue.
Tests are added for this issue.
Note: I also added `WriteValueWithIndentation_MapWithEmptyNested` to ensure this change would break things, but I doubt if it's necessary. Let me know whether to remove it.
Closes#15836
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/15836 from q42jaap:main 2b9399ba0c
PiperOrigin-RevId: 607000434
# 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
There is a new trimming/AOT warning in JSON formatter enum handling. I have fixed it by suppressing the value.
I also tested the solution with the .NET 8 SDK and suppressed some other warnings that came up (they're already handled).
It would be great to include this fix in a 25.x release.
Closes#14789
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/14789 from JamesNK:jamesnk/enum-trimming-warning d64dda15f0
PiperOrigin-RevId: 592306588