This better shows the semantic of the API. For already setted fields,
mergeFromString do replacement for singular fields and appending for
repeated fields.
* 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.
- 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.)
