FieldDescriptor.HasPresence returns true if both ClearValue and HasValue (on the accessor) can be expected to work. Some fields have a working ClearValue, but no HasValue; HasPresence returns false for those fields.
Generally:
- Extension fields have presence if and only if they're singular
- Repeated fields do not support presence
- Map fields do not support presence
- Message fields support presence
- Oneof fields support presence (this includes synthetic oneof fields, so that covers proto3 optional singular fields)
- Proto2 singular primitive fields support presence
- Proto3 singular primitive fields do not support presence (unless they're in a oneof, covered above)
This is a breaking change in terms of proto2 code generation: users who were previously using these members will have to change to null checks for message fields.
After toying with removing Has/Clear for proto2 oneof fields, I've left them alone in this commit, for consistency with other languages. The inconsistency between proto2 and proto3 won't come up here, because proto3 oneof fields can never be explicitly optional.
Fixes#7395.
It is no longer possible to "bundle install" these versions:
$ bundle install
Fetching gem metadata from https://rubygems.org/.................
reline-0.1.3 requires ruby version >= 2.5, which is incompatible with the current version, ruby 2.4.9p362
This is a breaking change in terms of proto2 code generation: users who were previously using these members will have to change to null checks for message fields.
After toying with removing Has/Clear for proto2 oneof fields, I've left them alone in this commit, for consistency with other languages. The inconsistency between proto2 and proto3 won't come up here, because proto3 oneof fields can never be explicitly optional.
Fixes#7395.
* Added changelog for 3.12.x.
* Updated the wording of the changelog for proot3 presence.
Also removed notice for change that was rolled back for
Java enums.
* A bit more teaking of the wording.
- Bump the version marker in the generated code.
- Set the flag to say clear on zero is known.
- Set clear on zero for proto3 optional fields that aren't tagged as optional.
- Also tweak the call from some C generated code to use different apis with
better validation.
- Mark the ObjC generator as supporting the proto3 optional feature.
- Regenerate the WKTs to get the new flags.
- With the new flags, the syntax isn't needed, so don't pass it.
- To keep library binary compatibility, rename the helpers since one
"Internal" method was called from generated code. Keep a shim with
the old signature to support those generated sources.
- Add a Descriptor flag to capture if the field should clear on being zeroed.
- Update the runtime to use the new clear on zero flag.
- Add a flag on message initialization to indicate the sources were generated
with/without this support so the runtime can backfill the flag for older
generated sources.
- Don't make an OneofGenerator for synthetic oneofs.
- Update the field calculations that determine if hasbits are needed to
know about synthetic oneofs and ignore them.
FieldDescriptor::has_presence works as a replacement for the custom logic we
had for FieldGenerator::WantsHasProperty(), and is already proto3 optional
aware.
The changes in the existing proto2 code are solely around presence bits. The new generator allocated presence bits more efficiently. (Previously bits were sometimes allocated but never used.)
Most changes are:
- Introducing new helpers of SupportsPresenceApi and RequiresPresenceBit. This allows calling code to be a lot clearer about what it's interested in.
- Changing most previous IsProto2 calls to use one of the two new helper methods
- Avoiding treating synthetic oneofs as regular ones
- Some slight refactoring in csharp_primitive_field to avoid code duplication
- Comments explaining what we want when, so the next maintainer doesn't need to do the detective work I did!
This change deliberately doesn't modify the API surface of any
existing code. The only change to previously-generated C# should be
making presence bits more efficient in proto2.
Once proto3 optional fields are supported, we can consider further
changes to make the proto2 and proto3 generated API surface more
consistent (e.g. adding presence API for message fields and oneofs).