-Raise warnings for deprecated google/protobuf/service.py APIs.
service.py APIs are marked as deprecated since 2010. These APIs will be
removed in Jan 2025
PiperOrigin-RevId: 653280370
We are seeing in profiles that this constructor is calling the other constructor.
It doesn't seem to be totally inlined, as the times spent in each constructor
stack frame are different.
In the common case of no builderParent, the constructor can be empty.
PiperOrigin-RevId: 653272368
By changing the return type to `auto`, we can handle `std::string` and other
types in a single definition without needing a separate overload.
PiperOrigin-RevId: 653272253
We were failing to propagate the DefPool's platform to the MiniDescriptor builder. This caused upb's code generators to incorrectly generate a field rep of `kUpb_FieldRep_8Byte` for pointer-typed extension fields instead of the 32-bit clean output:
```
UPB_SIZE(kUpb_FieldRep_4Byte, kUpb_FieldRep_8Byte)
```
PiperOrigin-RevId: 653263168
Rust protobuf is in development and not intended for use / released yet. We should add this back at some point when rust is ready for release, after adding equivalent GHA presubmit tests.
PiperOrigin-RevId: 653252995
Our ASAN test runs have not had the heap checker enabled, so this has allowed a
few memory leaks to slip in. This CL fixes all of them so that we can turn on
the heap checker.
The first one takes place whenever we add an entry into a string-valued map
using the C++ kernel. The problem is that `InnerProtoString::into_raw()` gives
up ownership of the raw `std::string` pointer it holds, but then we never
delete that pointer. This CL fixes the problem by deleting the pointer in C++
right after we perform the map insertion. To simplify things, I created a
`MakeCleanup()` helper function that we always call in our map insertion
thunks, but it's a no-op in the cases where we don't need to free anything.
There were a couple similar memory leaks related to repeated field accessors in
the C++ kernel, and those were simple to fix just by adding the necessary
`delete` call.
Finally, there were two benign memory leaks in the upb kernel involving global
variables used for empty repeated fields and maps. It turned out that we did
not need to use `Box` at all here, so removing that simplified things and fixed
the leaks.
PiperOrigin-RevId: 652947042
Create WORKSPACE.bzlmod. Before building with Bzlmod resulted in use of full WORKSPACE.
Some repos are still there, but the file should eventually be empty.
Add dep to rules_kotlin 1.9.0. This was the first version available on BCR. It pushed upgrade of
rules_jvm_external to 6.0 and rules_java to 6.5.2 (keep 6.0.0 on Bazel 6.3.0).
Add missing maven and other deps to MODULE.bazel
CI changes:
Disable Bazel 6.4.0 with bzlmod. rules_jvm_external 6.0 use use_repo_rule, which is not supported by Bazel 6.
Add C++ build "Bazel7 with Bzlmod" enabled.
Add Java builds with "Bazel 7 with/without Bzlmod".
Fixes: https://github.com/protocolbuffers/protobuf/issues/17176
PiperOrigin-RevId: 652773197
The implementation takes ownership of the `printer`. But, the current method signature does not make it clear whether ownership is taken. In fact, since it's a `const *`, it could be easily confused by the callers as _not_ taking ownership.
All other `Register...Printer()` methods have comments about taking ownership. This is the only one that was left out.
PiperOrigin-RevId: 652584898
- Follow upb and only accept the first value for `type_id` and `message`
- Reflow some of the logic to hopefully make things a little easier to follow/clear.
- Validate some more assertion about things the extensions for a MessageSet.
PiperOrigin-RevId: 652545240
`absl::string_view`.
Added temporary macro `PROTOBUF_TEMPORARY_ENABLE_STRING_VIEW_RETURN_TYPE` to turn on the new return type before the breaking change happens. It allows users to test and update their code ahead of time.
PiperOrigin-RevId: 652517294
These APIs were intended to support an internal-only mutable implementation of Java protobuf and should not actually be used in open source. Removal of these APIs shouldn't break anyone -- the equivalent immutable methods should be used instead.
PiperOrigin-RevId: 651833683
Enable the Starlark rule only on Bazel versions, that have the Starlark version of ProtoInfo provider. That's needed, because only that exposed _transitive_proto_info field that's used in the rule.
PiperOrigin-RevId: 651753437