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
Rewrite compile tests from BazelProtoCommonTest to Starlark. This is using rules_analysis for testing.
The tests are super fast (cca. 1s for all of the to run).
The tests work either with a redirect (calling native rule) or with actual implementation in the protobuf repository.
PiperOrigin-RevId: 651748083
Move toolchain helpers into a separate private file. After the migration those should be removed, so let's not make it a new public APIs. Copybara also handles differences in toolchain type labels.
Remove ProtoLangToolchainInfo from proto_common. Providers need special care when moving and will be moved last.
Read INCOMPATIBLE_ENABLE_PROTO_TOOLCHAIN_RESOLUTION from native proto_common. This is a BuildLanguageConfiguration flag (load time flag) and may only be read through native support. Add a dependency to the latest bazel_features that supports this check. On older Bazel versions fail if ALLOWLIST is configured.
Implement version check for PackageSpecificationInfo. It's only available after Bazel 6.4.0.
The rest of the implementation matches Bazel version. Tests are quite extensive and will be submitted in separate PRs.
PiperOrigin-RevId: 651699412
General test for it is done in Rust, and then extensions are tested in UPB as they're not currently supported in Rust-upb.
PiperOrigin-RevId: 651113583
Ensure all apis are called directly in tests.
Correct `GPBUnknownField` `-copy` to not have to make a new instance
since it is immutable in the new form.
PiperOrigin-RevId: 650690942
Port of the interesting `GPBUnknownFieldsSet` tests to `GPBUnknownFields`
as they provide coverage of general handing of unknown fields during parsing.
Also tweak the `Set` tests to actually use a registry to confirm behaviors around
extensions where the test previously wasn't as complete.
PiperOrigin-RevId: 650660181
Looking at the code history, this test used to try two different ways to construct a proto containing map fields, and check that the resulting protos were the same. One of the ways was to obtain mutable `Map` objects for the fields, and modify those. When that possibility was removed from the proto API, the test code that used it was changed to use the other way,
map-modifying methods directly on the proto class. But the end result is that the test method here was just doing the same thing twice and checking that it got the same result.
PiperOrigin-RevId: 650639933
Move some of the new logic out of `GPBUnknownField` so it will end up as a much
simpler "container", with all the serialization logic inside `GPBUnknownFields`
instead.
Also move some of the internal logic needed into static C functions to reduce the
ObjC class overhead of `GPBUnknownFields`.
This was all inspired by realizing during serialization related apis the `type` of
each field was being examined multiple times and reduces that in addition to reducing
the number of methods being invoked.
PiperOrigin-RevId: 650631975
Calling into_proxied() already does a copy and before this change we were doing a second one.
I am not using set_allocated_<field(std::string* s) because the method is not generated when [features.(pb.cpp).string_type = VIEW] is specified.
PiperOrigin-RevId: 650612909
* The public Repeated::{push, set} and Map::insert methods now accept any value that implements IntoProxied<T>, allowing us to move owned values instead of copying them.
* This change also updates the FFI layer for strings/bytes in the repeated and maps thunks to accept a std::string* that can be moved rather than a PtrAndLen type that needs to be copied.
* Tests are updated to no longer .as_view() when setting a message / string on a repeated / map field. The IntoProxied trait makes calling .as_view() obsolete.
PiperOrigin-RevId: 650580788
This is a performance optimisation that avoids us going through from
AbstractList.add(E) to LazyStringArrayList.add(int index, String) and then
having to call the index-based add in ArrayList, which has more bookkeeping
around moving elements across if necessary.
We can avoid that bookkeeping by adding this overload.
Also, group together overloads to squash a style warning.
PiperOrigin-RevId: 650089286
This should slightly speed things up.
Should be safe: these operations don't change the number of entries inside the loop.
PiperOrigin-RevId: 650087172
Protobuf Team Bot
Sandy Zhang
Hong Shin
Tony Liao
Protobuf Team Bot
Marcel Hlopko
Mark Hansen
Mike Kruskal
Thomas Van Lenten
Éamonn McManus
Jakob Buchgraber
Eduardo Menges Mattje