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.
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