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).
This includes instructions for enabling explicit presence tracking in proto3, and also explains implicit presence. The language examples were written by inspection, and not individually tested.
* WIP.
* WIP.
* Builds and runs. Tests need to be updated to test presence.
* Ruby: proto3 presence is passing all tests.
* Fixed a bug where empty messages has the wrong oneof count.
Since our (public) generated APIs document their use of repeated fields, we should probably document its API, too.
This includes some changes to generate_docs.py to explicitly allow named modules, since the repeated field implementation lives in the "internal" tree.
