Swift generators should default to CamelCasing the proto package and prefixing
symbols with that, but this option allows developers to override that behavior
with something custom if they desire.
Fixes https://github.com/google/protobuf/issues/1833
This seems to be necessary to prevent warnings in some compiler
configurations, particularly for tag numbers that are too large to fit
in a signed 32-bit int.
This change fixes the following Chromium presubmit error:
third_party/protobuf/csharp/src/Google.Protobuf.Test/project.json could
not be parsed: Expecting property name: line 25 column 3 (char 482)
This affects cases with leading capital letters.
This breaks compatibility with previous C# releases, but
fixes compatibility with other implementations.
See #2278 for details.
This check adds a few constraints on the way to build a project when we have
a proto file which imports another one. In particular, on projects which
build both C# and Java, it's easy to end up with exceptions like
Expected: included.proto but was src/main/protobuf/included.proto
A user may work around this issue, but it may add unnecessary constraints
on the layout of the project.
According to f3504cf3b1 (diff-ecb0b909ed572381a1c8d1994f09a948R309)
it has already been considered to get rid of this check, for
similar considerations, and because it doesn't exist in the Java code
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...
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#.)
Thomas Van Lenten
Adam Cozzette
Julien Brianceau
Msp
Jon Skeet
Bo Yang
Feng Xiao
Jan Tattermusch
Guillaume Turri
Jisi Liu
Jon Skeet
Jos Hickson
detlevschwabe
Luke Bakken