We can't directly use std::atomic because Extension needs to be trivially copyable.
Also move the Extension member functions before the data members to comply with Google C++ style guide.
PiperOrigin-RevId: 653701040
This should provide the roughly same result as ctype, except that it reflects actual behavior rather than the specification in the proto file. VIEW will now be visible, and some subtleties around CORD and PIECE will change.
PiperOrigin-RevId: 653677655
Motivation: these accessors (e.g. size(), Capacity()) will have branches on `is_soo()` so it's best to avoid calling them repeatedly if we can instead save the result in a local variable.
Also update some comments to avoid referring to the names of data members that will no longer exist with SOO.
PiperOrigin-RevId: 653672810
Rather than two traits (MutProxy subtrait of ViewProxy), instead have three traits (MutProxy subtrait of Proxy, and ViewProxy subtrait of Proxy).
This makes things more consistent, including that (MutProxied subtraits Proxied) is now more parallel to (MutProxy subtraits Proxy).
ViewProxy is largely a marker trait here but leaves a spot for methods that should be on ViewProxies but not MutProxies if those do show up later.
PiperOrigin-RevId: 653661953
Use paths.is_normalized and paths.is_absolute from bazel skylib. Upgrade skylib to latest version that has the implementation.
Use copybara for the differences in STRIC_DEPS_FLAG_TEMPLATE.
Implement native_bool_flag to read native flags and use them in proto_library. Those are implemented in such a way, that they can be replaced in place with starlark bool_flag targets.
Implement version check for PackageSpecificationInfo. It's only available after Bazel 6.4.0.
Tests will be submitted in separate PRs.
PiperOrigin-RevId: 653532601
This may save some alloactions if java's intrinsics aren't smart enough to avoid the roundtrip. But most JVMs probably have smart enough intrinsics, so this is probably not going to speed things up, just make the code look nicer.
PiperOrigin-RevId: 653445330
I believe they have intrinsics even for the long-form Integer.compareTo(Integer.valueOf(a), Integer.valueOf(b)) format which avoids the intermediate allocation.
So this probably won't make things faster, just makes the code a little cleaner.
Integer.compare was added in Java 1.7 which seems safe. Added to Android in SDK 19, which is less than the 21 minSDK supported by protobuf: 303239d74d
PiperOrigin-RevId: 653438420
-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
Evan Brown
Protobuf Team Bot
Mike Kruskal
Protobuf Team Bot
Derek Benson
Mark Hansen
Cong Liu
Jie Luo
Adam Cozzette
Joshua Haberman
Sandy Zhang
Tony Liao
Thomas Van Lenten