`Vec<u8>` is a more idiomatic Rust type to return for serialization.
For the C++ kernel, we are able to return this type with no extra copying. We
still use `SerializedData` type for FFI, but convert the result into a
`Vec<u8>` using a new `into_vec` method.
The upb kernel serializes onto an arena, so for upb we do need to copy the data
to get it into a `Vec<u8>`.
PiperOrigin-RevId: 644444571
Hi,
We get a compiler warning in MSVC that a signed/unsigned comparison is executed.
The warning is at around line 1073 in src/google/protobuf/map.h
```cpp
ABSL_DCHECK_GE(new_num_buckets, kMinTableSize); // <-- signed/unsigned comparison
const auto old_table = table_;
const map_index_t old_table_size = num_buckets_;
num_buckets_ = new_num_buckets;
```
This is due to `kMinTableSize` is a enum value. Probably a C++98 way to enforce constexpr.
This PR changes `kMinTableSize` to be a constexpr unsigned `map_index_t` and removes the casts instead of fixing the warning with a cast at ne 1073.
It seems like `kMinTableSize` is correlated with the `TableSize` of this class, which is map_index_t. Therefore the min value can at maximum the max value of map_index_t. And the min value of `kMinTableSize` can also not be negative, as this makes no sense.
It is also nicer to have fewer casts.
Closes#17013
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17013 from TinyTinni:removes-msvc-warning-map 4f954e8c9b
PiperOrigin-RevId: 644207177
I've made a new name for the interface, ExtensionSerializer, so we can keep ExtensionWriter in the same place for backwards-compatibility for a little while.
PiperOrigin-RevId: 644172922
These classes are deprecated and will be removed in the next breaking change. Users should update gencode to >= 4.26.x which uses GeneratedMessage instead of GeneratedMessageV3.
Tested with //compatibility:java_conformance_v3.25.0 which builds the runtime against 3.25.0 gencode.
PiperOrigin-RevId: 644136172
If we have a `oneof Foo` in a message `Bar`, we should access the discriminator as `Bar.Builder.fooCase` rather than `Bar.Builder.getFooCase()`.
PiperOrigin-RevId: 644107242
Fixes#16894
It is tested on command execution only, where it fixes the issues of reported memory leaks, heap corruption and segmentation fault.
I could not run tests on my Mac because of #16944Closes#16993
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/16993 from simonberger:bugfix/php-ext-persistent-global-corruption 62b5529b6a
PiperOrigin-RevId: 644034181
This extends previous workaround for java features in unknown fields, to include features extensions that are known but use a mismatched descriptor.
This can happen when users bring their own descriptors via buildFrom.
PiperOrigin-RevId: 644013578
This was introduced by the previous fix for delimited inheritance, and was never released. This fix removes all getType() calls from crosslink, where it's not safe to inspect the message type, which is still a placeholder, until after crosslinking. Using the inferred type is not necessary since we treat messages and groups the same during crosslink.
PiperOrigin-RevId: 643394981
Since statically tree shaken messages can never later become linked, we should not need to use any of the special code in the decoder. By using a distinct "empty" message type, we avoid triggering any of this special behavior. This avoids bugs around hazzers and other presence checks.
Also fixed a bug in the cmake staleness test that was causing test failures.
PiperOrigin-RevId: 643036818
New code should prefer `features.(pb.cpp).string_type`. We can't use the `deprecated=true` option for now due to failing tests.
PiperOrigin-RevId: 643036543
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
Adam Cozzette
Jason Lunn
Matthias Möller
Mark Hansen
Sandy Zhang
Protobuf Team Bot
Congcong Cai
Éamonn McManus
Benoît Quenaudon
Simon Berger
Mike Kruskal
Jie Luo
Protobuf Team Bot
Joshua Haberman
Hong Shin
jensbjorgensen
Derek Benson
h-vetinari
Marcel Hlopko
Dave MacLachlan