In translation units relying heavily on protobufs, this leads to a reduction of around 1% of the number of nodes in the AST.
PiperOrigin-RevId: 641170174
New serialization test will verify the amount of bytes it takes to serialize a message with a field of type INT32 set to different values.
PiperOrigin-RevId: 641044189
Because we parse options into the generated pool for *all* descriptor pool builds, it's important that it's properly initialized. Notably, if the C++ feature extensions haven't been registered we can end up with crashes from files that specify them.
PiperOrigin-RevId: 641043996
The recent github runner image update changes the MSVC version, and InitializeLog now crashes in optimized builds. Until Abseil works with MSVC, we can just log to stderr in protoc.
PiperOrigin-RevId: 641024759
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