`Any.TypeName` used `str.split` to extract the second part of the type URL
(potentially the only if there's no slash). `str.rpartition` has the same
effect and avoids constructing a list.
PiperOrigin-RevId: 687385575
This CL migrates messages, enums, and primitive types all onto the same blanket
implementation of the `ProxiedInMapValue` trait. This gets us to the point
where messages and enums no longer need to generate any significant amount of
extra code just in case they might be used as a map value.
There are a few big pieces to this:
- I generalized the message-specific FFI endpoints in `rust/cpp_kernel/map.cc`
to be able to additionally handle enums and primitive types as values. This
mostly consisted of replacing `MessageLite*` parameters with a new `MapValue`
tagged union.
- On the Rust side, I added a new blanket implementation of
`ProxiedInMapValue` in rust/cpp.rs. It relies on its value type to implement
a new `CppMapTypeConversions` trait so that it can convert to and from the
`MapValue` tagged union used for FFI.
- In the Rust generated code, I deleted the generated `ProxiedInMapValue`
implementations for messages and enums and replaced them with
implementations of the `CppMapTypeConversions` trait.
PiperOrigin-RevId: 687355817
There is an old convention that a `proto_library` target with empty `srcs`
should re-export its dependencies. This is sometimes useful as a way of
creating something like an alias target, except that it can point to multiple
dependencies rather than just one.
The `rust_proto_library` aspect currently cannot handle this pattern and will
raise an error if it encounters a `proto_library` without `srcs`. This CL fixes
that problem by updating the `RustProtoInfo` provider generated by the aspect
to include a list of `DepVariantInfo` instead of just one. In the typical case
the provider will have just one `DepVariantInfo`, but this gives us the ability
to return more than one in the case where we're exporting all the dependencies
of a `src`-less `proto_library`.
One thing this CL specifically does not attempt to do is add support for a
`rust_proto_library` directly wrapping a `proto_library` without `srcs`. The
reason for that is that it appears difficult to do in a way that would respect
the layering check. It's also not obvious that we would want to encourage this
pattern anyway. It's still valuable to support `src`-less `proto_library`
targets when they're somewhere else in the transitive dependencies. This way
you can freely create a `rust_proto_library` without having to fix up all your
transitive deps first.
PiperOrigin-RevId: 687344284
When you call a map field setter, we currently make an unnecessary extra copy,
so this CL fixes that problem.
I followed the example of how we already handle this for repeated field
setters. This required adding a new move setter thunk for map fields with the
C++ kernel. Originally I tried instead to add an FFI endpoint that could swap
two `RawMap` pointers, but it turned out to be difficult to implement this in a
way that worked correctly when the two maps are not on the same arena.
PiperOrigin-RevId: 687334655
The upgrade of rules_java also upgrades error prone and this resulted in some additional errors reported in Protobuf's tests. Set the flag to report those as warning, but they should be cleaned up eventually.
PiperOrigin-RevId: 687070204
macos-12 runner image is deprecated and is EOL 12/3/24 per https://github.com/actions/runner-images/issues/10721
Note that Python 3.8 is EOL and these tests should also be dropped / upgraded in
favor of 3.9 soon anyways.
#test-continuous
PiperOrigin-RevId: 687002433
upb headers are not in `${protobuf_SOURCE_DIR}/src`, so the `string(REPLACE ...)` command fails and the `save-installed-headers.vcxproj` contains an invalid path regarding upb headers, causing a failure in compilation.
Closes#18135
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18135 from Delcaran:main 28c40493e3
PiperOrigin-RevId: 686963169
This also prevents the validate_yaml script from erroring when trying to log that a step is mishandling continuous-run / continuous-prefix
PiperOrigin-RevId: 686952188
There is really no reason for the Java compiler code to call into the internal
C++ implementation of HasHasbit. In the future, the two implementations may
evolve separately and this decoupling can make it easier.
PiperOrigin-RevId: 686672397
See abseil release notes:
https://github.com/abseil/abseil-cpp/releases/tag/20240722.0
This is necesary pre-work to enable C++17 builds in preparation of baseline C++
upgrade from C++14 to C++17. C++14 support is scheduled to reach EOL on
2024-12-15:
https://github.com/google/oss-policies-info/blob/main/foundational-cxx-support-matrix.md
Interestingly enough, the older Abseil version 20230802.1 is actually OK for
building on macOS with C++17. However, we depend on GoogleTest, and they
transitively depend on Abseil version 20240116.2, which caused Bazel to
implicitly change the Abseil dependency to most recent specified version of
20240116.2:
https://github.com/google/googletest/blob/main/MODULE.bazel
Current builds with C++17 and Abseil version 20240116.2 on older macos versions
that didn't support `std::filesystem::path` would give the following error:
> error: 'path' is unavailable: introduced in macOS 10.15.
With this version upgrade, we pull in an Abseil patch that fixes this issue on
macOS:
65a55c2ba8
PiperOrigin-RevId: 686670268
Protobuf Team Bot
Hong Shin
Tony Liao
Protobuf Team Bot
Adam Cozzette
Mike Kruskal
Sandy Zhang
Matteo
Mark Hansen
Mike Kruskal
dependabot[bot]
Jie Luo