This won't remove all possibilities of naming collisions, but will address the simplest ones.
The "test" is just to add all the reserved names in a proto file: if the generated code builds, it works.
Note that before this change, using any of these field names would result in a compile-time error, so this is not a breaking change.
Generated code is in the next commit.
Fixes#8810
This doesn't test *all* possibilities (e.g. the field being a
wrapper, or a message field, etc) - but I'm fairly confident that I
found all the places referring to the case.
The NullValue enum is typically used as part of the Value well-known type, but can be used elsewhere. In previous code, a NullValue field (other than in Value) would result in a JSON value of the string "NULL_VALUE"; it should instead be the null literal.
When parsing, we still accept "NULL_VALUE" as a valid value for NullValue - this new code being unable to parse old data, and comes for free anyway.
If messages A and B have the same oneof case, which is a message
type, and we merge B into A, those sub-messages should be merged.
Fixes#3200.
Note that I haven't regenerated all the code, as some of the protos
have been changed, breaking generation.
This commit includes changes to the C#-specific protos, and rebuilt versions of the "stock" protos.
The stock protos have been locally updated to have a specific C# namespace, but this is expected to change soon, so hasn't been committed.
Four areas are currently not tested:
1) Serialization - we may restore this at some point, possibly optionally.
2) Services - currently nothing is generated for this; will need to see how it interacts with GRPC
3) Fields beginning with _{digit} - see https://github.com/google/protobuf/issues/308
4) Fields with names which conflict with the declaring type in nasty ways - see https://github.com/google/protobuf/issues/309
Joshua Haberman
Jon Skeet
Sandy Zhang
Mike Kruskal
Joshua Haberman
listonjesse
Xiang Dai
Feng Xiao
Jie Luo
alien
Jon Skeet