This was previously fixed in C++ (https://github.com/protocolbuffers/protobuf/issues/16549), but not ported to other languages. Delimited field encoding can be inherited by fields where it's invalid, such as non-messages and maps. In these cases, the encoding should be ignored and length-prefixed should be used.
PiperOrigin-RevId: 642792988
The noop code was causing big .proto files to time out even though it had no
effect in the compilation after optimizing.
We tried avoiding the extra complexity of preprocessor checks on each use, but
it seems necessary for now.
PiperOrigin-RevId: 642691974
Picking up #14981 from @dawidcha after several months of radio silence.
Quoting the OP of that PR:
> I have been collaborating with the grpc developers to make it possible to build that library as a Windows DLL - a couple of PRs were already merged, more like [grpc/grpc#34345](https://github.com/grpc/grpc/pull/34345) are pending.
>
> The grpc library incorporates some upb-generated, and upbdefs-generated code into grpc.dll, which is referenced by other code that consumes the library. Since this is now a DLL, that code doesn't know how to link to these generated symbols because they are not annotated with __declspec(dllimport).
>
> This PR aims to fix that by introducing a parameter 'dllexport_tag' to the upb and upbdefs plugins. That parameter should be a string e.g. MYAPP_DLL and when set, the extern symbols are annotated with a macro with that name. This can either be set externally to __declspec(dllimport) or, as is usual practice, when compiling code into a DLL, the macro <dllexport_tag>_EXPORT (i.e. MYAPP_DLL_EXPORT) is defined, and when consuming the DLL <dllexport_tag>_IMPORT is defined if neither are defined then the MYAPP_DLL macro becomes empty string which is what you want for building a static library.
>
> This is a continuation of #14230
>
> Fixes: #14255
Towards #13726Closes#14981Closes#17079
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17079 from h-vetinari:add_dll_tags 34927b1dde
PiperOrigin-RevId: 642622258
In this first stage, we rename the directory from protos_generator to hpb_generator, updating all necessary BUILD files and #includes.
PiperOrigin-RevId: 642600953
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