Timestamp and Duration are now have more support with datetime and timedelta:
- Allows assign python datetime to protobuf DateTime field in addition to current FromDatetime/ToDatetime (Note: will throw exceptions for the differences in supported ranges)
- Allows assign python timedelta to protobuf Duration field in addition to current FromTimedelta/ToTimedelta
- Calculation between Timestamp, Duration, datetime and timedelta will also be supported.
example usage:
from datetime import datetime, timedelta
from event_pb2 import Event
e = Event(start_time=datetime(year=2112, month=2, day=3),
duration=timedelta(hours=10))
duration = timedelta(hours=10))
end_time = e.start_time + timedelta(hours=4)
e.duration = end_time - e.start_time
PiperOrigin-RevId: 640639168
The functionality is enabled when the `proto_one_output_per_message` option used by C++ Lite is enabled.
This mirrors the behavior of C++ lite protos.
PiperOrigin-RevId: 640592937
This change adds a cfg attribute 'cpp_lite' to the C++ kernel of Protobuf Rust. If C++ lite is selected on the command line, the cfg attribute 'cpp_lite' is set. The root cause of the test failure was that the Debug implementation for full C++ protos uses text proto which is not available in C++ lite. The fix uses the 'cpp_lite' cfg attribute to select a different Debug implementation that doesn't rely on text proto
PiperOrigin-RevId: 640552701
Since the fixed/overridable split can occur whenever a feature is introduced or removed, we need to include those editions in the resulting compiled defaults. This does bug only affects edition 2024 and later, where features may be removed or introduced in isolation.
PiperOrigin-RevId: 640267061
We introduce Ptr removal so that our helper functions can be agnostically passed in a Ptr<T> or a T*.
We utilize SFINAE to determine if PtrOrRaw. If the target is const, or not in {T, T*, Ptr<T>}, the template will not match and be discarded (but still compile successfully).
PiperOrigin-RevId: 640198851
message.
Generating declarartions for all nested types is wasteful, and incorrect when
some nested type happens to refer to the parent type. The latter would create
two declrations for the same symbol in the .pb.cc file.
PiperOrigin-RevId: 640142695
If a plugin doesn't support a feature used by a proto file, we can't trust any errors reported by that plugin. We should always report these types of errors first. There could be cases where the plugin doesn't correctly specify its support when it hits an error though, so we should *also* report any plugin errors to avoid masking them.
PiperOrigin-RevId: 639984803
When enabled, all message instances inject their `ClassData` object into `MessageLite` to be stored there instead of the system generated vtable pointer. It replaces all virtual functions and destructor with alternatives using the custom vtable instead.
When disabled, this CL has no effect. The ClassData class is unchanged, and all existing virtual functions remain as they currently are.
Using a custom vtable will allow us to control the ABI of the type, opening the door to more efficient operations.
PiperOrigin-RevId: 639033776
The test I am removing fails on 32-bit ARM, as pointers are 4-byte aligned. `upb_MessageValue` is a union. The alignment of a union is the max. alignment of any of its fields. Among the fields are 8-byte types like u64 and thus `upb_MessageValue` is 8-byte aligned even on 32-bit ARM. 4 != 8 and it fails.
I am split on the usefulness of the test, as I find it somewhat unlikely to catch any divergence between the FFI and C types in the future. I can't imagine a practical scenario where upb_MessageValue would change in C code and this test would fail. IMO our actual unit & integration tests plus the IFTT lints are much better guards.
We could fix the test by testing the alignment of u64 instead of *const c_void, which is always 8 bytes on the hw platforms we care about.
PiperOrigin-RevId: 638976482
Use old-style for loop instead.
This should speed up processes that serialize many unknown fields, and reduce some GC pressure.
PiperOrigin-RevId: 638889708
This should not be needed for generated code, but may be needed for user calls to the public buildFrom method. FileDescriptorProto should really be parsed with java features in the extension registry (like other extensions), but we can handle this in Java runtime to ease editions adoption.
PiperOrigin-RevId: 638715579
This change has no effect in behavior, but makes future changes smaller.
- Make `Message` and `MessageLite` constructors protected.
- Make ClassData objects namespace scope globals instead of function scope. This will allow taking their address without calling a function.
- Replace direct calls to `~MessageLite()` with a helper function.
PiperOrigin-RevId: 638676816
Added the following methods:
serialize_length_prefixed(message: Message, output: io.BytesIO) -> None
parse_length_prefixed(message_class: Type[Message], input_bytes: io.BytesIO) -> Message
The output of serialize_length_prefixed should be BytesIO or custom buffered IO that data should be written to. The output stream must be buffered, e.g. using
https://docs.python.org/3/library/io.html#buffered-streams.
PiperOrigin-RevId: 638375900
This doesn't _actually_ make the C++ Kernel path ever fail yet, but now that the API is a Result<SerializedData, SerializeError> it can be fixed as an implementation detail.
PiperOrigin-RevId: 638329136
Mike Kruskal
Protobuf Team Bot
Jie Luo
Protobuf Team Bot
Joshua Haberman
Jakob Buchgraber
Hong Shin
Grégoire
Mark Hansen
Sandy Zhang
Manuel