We now just perform the optimization within AddRange itself.
This is a breaking change in terms of "drop in the DLL", but is
source compatible, which should be fine.
* Improve exception throwing implementation in collections
* Implement RepeatedField.AddRange.
This fixes issue #1730.
* Optimize AddRange for sequences implementing ICollection
(Also fix a few more C# 6-isms.)
* Remove the overload for Add(RepeatedField<T>)
We now just perform the optimization within AddRange itself.
This is a breaking change in terms of "drop in the DLL", but is
source compatible, which should be fine.
This doesn't currently change the ordering in the implementation, but allows us to do so in the future.
We also need to change
https://developers.google.com/protocol-buffers/docs/reference/csharp-generated#singular
which states "Finally, unlike Dictionary<TKey, TValue>, MapField<TKey, TValue> preserves insertion order of entries."
(We can just remove that sentence, I think.)
Also added a standalone formatter test, for confidence.
Have validated that undoing the change in 835fb947 breaks the tests
(i.e. we are still testing that the change is required).
(There are documentation changes and new fields in descriptor.proto that have resulted
in changes to the serialized descriptor, but no breaking changes for C#.)
Overview of changes:
- A new C#-specific command-line option, legacy_enum_values to revert to the old behavior
- When legacy_enum_values isn't specified, we strip the enum name as a prefix, and PascalCase the value name
- A new attribute within the C# code so that we can always tell the original in-proto name
Regenerating the C# code with legacy_enum_values leads to code which still compiles and works - but
there's more still to do.
I've moved both protoc.exe and the proto files out of Google.Protobuf.
The .proto files aren't a slam-dunk, but it feels like they belong with protoc as you'd *use* them with protoc.
It's not clear to me whether we really need both an x86 and x64 version of protoc.exe, as x86 would work on 64-bit Windows anyway. Discuss :)
This makes no externally visible behavioral changes. Internally and non-behaviorally:
- We use a field (compiler-generated) to store the JsonName to avoid recomputing it repeatedly
- The documentation for JsonName is updated to reflect the meaning better
- Readonly autoprops and expression-bodied properties used where possible
This detects:
- An end-group tag with the wrong field number (doesn't match the start-group field)
- An end-group tag with no preceding start-group tag
Fixes issue #688.
This is a start to fixing issue #1212. It won't help for test protos,
conformance etc, but it will definitely be better than nothing, and
would have highlighted a change in descriptor.proto which broken C#
earlier.
Recently, descriptor.proto gained a GeneratedCodeInfo message, which means the generated code conflicts with our type.
Unfortunately this affects codegen as well, although this is a part of the public API which is very unlikely to affect hand-written code.
Generated code changes in next commit.
The usage of ICustomDiagnosticMessage here is non-essential - ToDiagnosticString
doesn't actually get called by ToString() in this case, due to JsonFormatter code. It was
intended to make it clearer that it *did* have a custom format... but then arguably I should
do the same for Value, Struct, Any etc.
Moving some of the code out of JsonFormatter and into Duration/Timestamp/FieldMask likewise
feels somewhat nice, somewhat nasty... basically there are JSON-specific bits of formatting, but
also domain-specific bits of computation. <sigh>
Thoughts welcome.
Jon Skeet
Jon Skeet
Feng Xiao
Jos Hickson
detlevschwabe
Luke Bakken
Jisi Liu
alien
avgweb
Jan Tattermusch
Jan Tattermusch