ctype can not be used for none string/bytes fields. ctye=CORD can not be used for extensions. A new macro PROTOBUF_FUTURE_REMOVE_WRONG_CTYPE is added that will be flipped for our next breaking release.
PiperOrigin-RevId: 555615362
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.
This is primarily for access to comments, which would be expected to be available in a protoc plugin.
The implementation has two fiddly aspects:
- We use a Lazy<T> to avoid building the map before cross-linking. An alternative would be to crosslink at the end of the constructor, and remove the calls to CrossLink elsewhere. This would be generally better IMO, but deviate from the Java code.
- The casts to IReadOnlyList<DescriptorBase> are unfortunate. They'll always work, because these lists are always ReadOnlyCollection<T> for a descriptor type... but we can't use IList<DescriptorBase> as that's not covariant, and it's annoyingly fiddly to change the field to be of type ReadOnlyCollection<T>.
unittest_proto3 had been changed in a very backward-incompatible
way which was never going to work with C# as it imports proto2 messages.
This is now a copy of the old file, but with a package name change for
compatibility with the remaining files in src/google/protobuf.
The other moves are for files that are only used by C#.
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 consists of:
- Changing the codegen for the fixed set of options protos, to parse unknown fields instead of skipping them
- Add a new CustomOptions type in the C# support library
- Expose CustomOptions properties from the immutable proto wrappers in the support library
Only single-value options are currently supported, and fetching options values requires getting the type right
and knowing the field number. Both of these can be addressed at a later time.
Fixes#2143, at least as a first pass.
- Remove some old proto2-based C#-only messages
- Remove the "build" directory which only contained out-of-date files
- Remove the csharp_namespace option from proto2 messages
- Change "Google.ProtocolBuffers" to "Google.Protobuf" in other messages
This is the start of establishing a C# namespace of "Google.ProtocolBuffers.TestProtos.Proto3" for proto3-syntax protos.
We could optionally split the directory structure as well into Proto2 and Proto3 for clarity.
Joshua Haberman
Jie Luo
Mike Kruskal
Jon Skeet
Protobuf Team Bot
Sandy Zhang
Joshua Haberman
listonjesse
Rafi Kamal
Brian Wignall
Sydney Acksman
Xiang Dai
Feng Xiao
Jie Luo
alien
Jon Skeet