* A few more cases for binary conformance tests.
* over-encoded varints (encoded in more bytes than are necessary).
* truncated varints (>32 bits for 32-bit types).
* Fixed Python decoding bug with 32-bit varints.
* Fixed 1L -> 1LL for 32-bit platforms.
* Factored Conformance test messages into shared test schema.
* Updated benchmarks to use new proto3 message locations.
* Fixed include path.
* Conformance: fixed include of Python test messages.
* Make maven in Rakefile use --batch-mode.
* Revert changes to benchmarks.
On second thought I think a separate schema for
CPU benchmarking makes sense.
* Try regenerating C# protos for new test protos.
* Removed benchmark messages from test proto.
* Added Jon Skeet's fixes for C#.
* Removed duplicate/old test messages C# file.
* C# fixes for test schema move.
* Fixed C# to use the correct TestAllTypes message.
* Fixes for Objective C test schema move.
* Added missing EXTRA_DIST file.
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.
If a message is proto3, then the zero values still count as being set one the
field is in a oneof.
Add tests to confirm oneofs work as expected in both syntaxes.
- Update ruby conformance generation for rename of generated files that seems
to have happened.
- Update gitignores for the above and for the no-warnings-test.
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.
If a message is proto3, then the zero values still count as being set one the
field is in a oneof.
Add tests to confirm oneofs work as expected in both syntaxes.
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.)
Josh Haberman
Paul Yang
Julien Brianceau
Adam Cozzette
Feng Xiao
Mark Costello
Jon Skeet
Bo Yang
Thomas Van Lenten
Jon Skeet
Otto Kekäläinen
Jisi Liu