Instead of using the message's corresponding field to denote the end of the stream, just abort it on *any* end group tag. If this is an invalid tag, the caller will handle the failure.
PiperOrigin-RevId: 622859234
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
# 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
We transformed the proto2/proto3 protos to editions, and then run the same set of tests over both. This will verify that migrating to editions preserves the same proto2/proto3 behavior. These will not be enabled by default, and require a flag `--maximum_edition=2023`.
Future changes will:
- add more targeted editions-specific tests
- clean up our conformance test framework to allow for more targeted tests
- add wildcards to failure lists in limited cases to reduce noise
- add feature resolution conformance tests
PiperOrigin-RevId: 574570607
Fixes#7486.
Note that this changes the behavior for message fields where
"WithFormatDefaultValues(true)" has been specified. This is
effectively fixing a bug, but will need to be noted in the release
notes.
Basically, FormatDefaultValues only affects fields that don't
support presence - most commonly, singular primitive non-optional
fields in proto3.
* Give a unique category to each test.
This change introduce a TestCategory enum to ConformanceRequest. Existing tests
are divided into three categories: binary format test, json format test and json
format (ignore unknown when parsing) test. For the previous two categories, there
is no change to existing testee programs. For tests with the last category, testee programs
should either enable ignoring unknown field during json parsing or skip the test.
* Fix python test
* Fix java
* Fix csharp
* Update document
* Update csharp generated code
* Reserve unknown in ruby
* Revert ruby tests. Wait for cpp impl for conformance test
* Add conformance test for preserving unknown
* Add unknown field conformance test to csharp failure list.
* Fix comments
* Fix comment
* Fix comments
* Fix typo
* Use stringsink_string directly
* Mark hd unused
* Remove unused encodeunknown_handlerfunc
Previously we only rejected the tag if the tag itself was 0, i.e.
field=0, type=varint. The type doesn't matter: field 0 is always
invalid.
This removes the last of the C# conformance failures.
Add note about JSON tests maybe being wrong.
- Add note about the JSON test maybe not being correct yet.
- Add test to checks the generated names for double underscores to be sure they
are what is expected.
This should fix the failures in the conformance tests - although
it highlights the problem that we need to do this when changing
the conformance.proto file...
Incase the different runtimes have different generation/implementations for
for the different primitive field types, cover a larger range of the proto
types in the oneof zero tests.
can reasonably be expected to be interoperable.
(The fact that not all Int64/Uint64 values *can* be exactly represented in
IEEE-754 and thus interoperably amongst JSON implementations is precisely the
reason for wrapping them when we serialize... it shouldn't be a surprise that
we can't round-trip in unwrapped form for all values.)
The tests are run from Travis in the same way as on other
platforms. Currently some expected failures - but only expected
in that they're what we got to start with. Will try to fix them in
other pull requests.
Mike Kruskal
Protobuf Team Bot
Anton Grbin
Sandy Zhang
Joshua Haberman
Jon Skeet
listonjesse
Sydney Acksman
Rafi Kamal
Feng Xiao
Paul Yang
Jie Luo
Jie Luo
Jisi Liu
Yilun Chong
Bo Yang
Thomas Van Lenten
Jon Skeet