Github dropped support for the current image:
https://github.com/actions/runner-images/issues/10559
There is a new image that has visionOS, but it is listed as
"beta", so it might make sense to wait and revisit when
generally updating the macOS images/tools.
PiperOrigin-RevId: 679264196
[ObjC] Disabling visionOS on CI.
Github dropped support for the current image:
https://github.com/actions/runner-images/issues/10559
There is a new image that has visionOS, but it is listed as
"beta", so it might make sense to wait and revisit when
generally updating the macOS images/tools.
PiperOrigin-RevId: 679264196
[ObjC] Disabling visionOS on CI.
Github dropped support for the current image:
https://github.com/actions/runner-images/issues/10559
There is a new image that has visionOS, but it is listed as
"beta", so it might make sense to wait and revisit when
generally updating the macOS images/tools.
PiperOrigin-RevId: 679264196
This is a very narrow edge case where touching a packed extension via generated APIs first, and then doing so reflectively will trigger a DCHECK. Otherwise, reflective APIs will work but not use packed encoding for the extension. This was likely a pre-existing bug dating back to proto3, where it would only be visible on custom options (the only extensions allowed in proto3).
To help qualify this and uncover similar issues, unittest.proto was migrated to editions. This turned up some other minor issues in DebugString and python.
PiperOrigin-RevId: 675785611
* 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
Protobuf Team Bot
deannagarcia
Deanna Garcia
esrauchg
Thomas Van Lenten
Mike Kruskal
zhangskz
Protobuf Team Bot
Joshua Haberman
Jingwen Chen
Eric Salo
Adam Cozzette
Jerry Berg