* 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.
Previously if you assigned 'nil' to a submessage in proto2
the field would be set to 'nil' but would still have its hasbit
set. This was a clear bug so I'm fixing it outright, even though
it is an observable behavior change.
* Create a new docker image for python 3.6
The previous one cannot build, because python3.6 was removed from
stretch.
* Drop support for 3.3 and 3.4
Also update all docker file to be single version
* Add a test suite for ruby 2.7
* Call BigDecimal() instead of BigDecimal.new()
BigDecimal.new was deprecated in ruby 2.6
* Switch FrozenError expectation to a matcher
The error message for FrozenError changed to include more information
about the mutated object. Switch from an exact match to an aproximate
match (equal => match). This does not change the prefix.
* We can safely ignore newest array methods from ruby 2.7
* Build extensions for Ruby 2.7
* Try installing bundler 2.x
* Try bumping rake-compiler-dock
* Use standard RCD images
* Avoid 'rake cross native' with rake-compiler-dock
* Use Ruby 2.5 for building Ruby <= 2.6
* Use rake-compiler 1.1.0
* Specify target
* Don't update Ruby test image for now
