The edition specification in proto files will remain unchanged, but it will be immediately converted to an enum by the parser. This gives us more control over the valid set of editions and simplifies ordering (just an integer comparison now). We plan to release exactly one edition per year.
PiperOrigin-RevId: 563261375
This can be used by non-C++ runtimes and generators to seed feature resolution. The output binary proto message will contain a mapping from edition to the default feature set, including whichever generator feature extensions are passed to protoc.
PiperOrigin-RevId: 563246376
- Check that the maximum edition is always after the minimum
- Make sure that the minimum edition gets included in the default mapping when it's necessary
PiperOrigin-RevId: 563236159
The edition specification in proto files will remain unchanged, but it will be immediately converted to an enum by the parser. This gives us more control over the valid set of editions and simplifies ordering (just an integer comparison now). We plan to release exactly one edition per year.
PiperOrigin-RevId: 563215992
This partially fixes https://github.com/protocolbuffers/protobuf/issues/10088. The test case from that bug significantly improves with this change. However we still have a global map that does not shrink, which can still create the appearance of leaking memory, as it will not be freed until the module is unloaded.
PiperOrigin-RevId: 563124724
This changes the code to use explicit constructors instead of aggregate initialization, which allows optimizations when creating and copying messages.
PiperOrigin-RevId: 563088162
Create message/internal/types.h as a new leaf header
Move map_entry.h from message/internal/ to collections/internal/ where it belongs
PiperOrigin-RevId: 562889855
These have preconditions around not self-swapping, so restrict is safe here.
Comparison of generated code for methods used by message_unittest,
vectorization improves.
PiperOrigin-RevId: 562810187
The Python comparison protocol requires that if an object doesn't know how to
compare itself to an object of a different type, it returns NotImplemented
rather than False. The interpreter will then try performing the comparison using
the other operand. This translates, for protos, to:
If a proto message doesn't know how to compare itself to an object of
non-message type, it returns NotImplemented. This way, the interpreter will then
try performing the comparison using the comparison methods of the other object,
which may know how to compare itself to a message. If not, then Python will
return the combined result (e.g., if both objects don't know how to perform
__eq__, then the equality operator `==` return false).
This change allows one to compare a proto with custom matchers such as mock.ANY
that the message doesn't know how to compare to, regardless of whether
mock.ANY is on the right-hand side or left-hand side of the equality (prior to
this change, it only worked with mock.ANY on the left-hand side).
Fixes https://github.com/protocolbuffers/protobuf/issues/9173
PiperOrigin-RevId: 561728156
Also tweaked the "simple wrapper" language since the implementation does not appear to delegate to JsonToBinaryStream() directly.
Closes#13581
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13581 from dimo414:dimo414-patch-1 7522ae1673
PiperOrigin-RevId: 561610218
Protobuf Team Bot
Mike Kruskal
Protobuf Team Bot
Jie Luo
Eric Salo
Joshua Haberman
Martijn Vels
Richard Levasseur
Adrian Sadłocha
Chris Kennelly
Thibaut Cuvelier
Cong Liu
Hong Shin
Michael Diamond