There is a special case where message factories can be confused: if a module
written in C++ with pybind11 links against a self-recursive message, and that
message is part of another message loaded from Python, then the confusion
will happen.
Example:
# This one is also linked into the C++ module.
message SelfRecursive {
optional SelfRecursive self_recursive = 1;
}
# This one is used only in Python and not linked.
message OnlyUsedInPython {
optional SelfRecursive self_recursive = 2;
}
The caching through message_factory::RegisterMessageClass then happens on one
instance of the factory, but traversal with the lookup in another.
This occurs in the pure Python and upb implementations that have their own
default descriptor pools (and thus message factory).
Fix this by using the already passed message factory to registering the
message class to cache.
A test accounts for this case to avoid regressions.
PiperOrigin-RevId: 642551744
For some reason it seems that `pb::*` does not match the type info symbol for
`pb::CppFeatures`. Ordinarily this does not seem to cause problems, but we
received a report about it causing issues with sanitizers:
https://groups.google.com/g/protobuf/c/ytkvjXXdG2g/m/hk7a5JnCAwAJ
For clarity I made the same change for `upb::`, though I don't think this is
strictly necessary since it is covered by the `*pb::*` glob.
PiperOrigin-RevId: 642390692
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: 642327960
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
Marcel Hlopko
Protobuf Team Bot
Protobuf Team Bot
Dave MacLachlan
Adam Cozzette
Joshua Haberman
Alex Eagle
Éamonn McManus
Hong Shin
Mike Kruskal
Jie Luo
Jakob Buchgraber