* Fix cord handling in DynamicMessage and oneofs.
This fixes a memory corruption vulnerability for anyone using cord with dynamically built descriptor pools.
* Silence expected ubsan failures from absl::Cord
---------
Co-authored-by: Mike Kruskal <mkruskal@google.com>
The toolchain type is consumed by proto_library and produced by proto_toolchain rule. As such it's a private dependency, because both rules are now part of protobuf repo.
There are some early adopters of --incompatible_enable_proto_toolchain_resolution that might be broken from this: grpc, rules_go, rules_ts, rules_rust, rules_lint, because they have implementation that is not using proto_common. Those repositories need to define their own proto_lang_toolchain and consume it with proto_common.compile.
PiperOrigin-RevId: 654897871
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
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
Introduce a upb_MessageValue_Zero() function to use for the cases we do want a zero'd union (typically a zero MessageValue union is not needed)
PiperOrigin-RevId: 672592274
For some reason, Clang 19 appears to raise an error in some situations unless
we explicitly inline the implementation of `StrongPointer()` here.
PiperOrigin-RevId: 669373421
This appears to be causing a bunch of errors during our release process,
but I don't think it's critical to have this flag in `.bazelrc`. We
should still be able to get about the same test coverage since we also
set `-Werror` in the `bazelrc` files in the `ci/` directory.
* Move -Werror to our test/dev bazelrc files.
Putting it into BUILD files unintentionally forces it on all our downstream users. Instead, we just want to enable this during testing and let them choose for themselves in their builds.
Note, that this expands the scope of -Werror to our entire repo for CI, so a bunch of fixes and opt-outs had to be applied to get this change passing.
Closed#14714
PiperOrigin-RevId: 666903224
* Fix extra warnings on 28.x
* Fix zlib issues on macos
* Second try at zlib/macos issues
* Only disable deprecated-non-prototype on macos-14
This should get use feedback so we know if usage, the intent is to
be able to remove the different generation code in the future if
folks don't need these.
PiperOrigin-RevId: 666318474
3.x.x descriptor.proto generated code is *not* supported with 4.x.x runtime, since this results in an ODR violation with the descriptor.proto built into the 4.x.x runtime. This is expected to result in undefined behavior / failures.
Tested against //java/core:v25_generated_message_test_jar (binary compatibility) and //java/core:v25_generated_message_test_srcjar (source compatibility)
PiperOrigin-RevId: 664819152
Since a group GPBUnknownField uses a GPBUnknownFields and that is mutable, it needs to be copied so two instances aren't linked.
PiperOrigin-RevId: 663323972
The api is annotated that it isn't valid, but incase someone calling code isn't
annotated correct and someone returns nil for another nonnull api, it could happen,
so make it an explicit failure just to be safe.
PiperOrigin-RevId: 662935009
Pure python and upb do not support it and filtered out the test. This API does
not exists in any other language(except protobuf c++).
GetDebugString() for cpp extension will be removed in Jan 2025
PiperOrigin-RevId: 662640110
Protobuf Team Bot
zhangskz
Protobuf Team Bot
Joshua Haberman
Jingwen Chen
Eric Salo
Adam Cozzette
Mike Kruskal
Jerry Berg
Thomas Van Lenten
Jie Luo