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
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
This ports upb's WORKSPACE scraping logic to protobuf, and allows us to dynamically fetch our dependencies at the exact same pinned version as in Bazel via protobuf_FETCH_DEPENDENCIES=ON. This is mostly for development purposes, and is preferable to git submodules. In a later cl we will flip the default behavior to "package"
#test-continuous
PiperOrigin-RevId: 686265348
This doesn't alleviate Bazel's problem. rules_rust are still fetched because they register toolchains themselves.
However the change pushes into the direction, where I believe that only the owning module should be concerned with its toolchain registration and the toolchain selection should be controlled via a flag mechanism or similar. Removing the registration now, can alleviate problems in the future, when we figure out how to prevent unnecessary fetches.
PiperOrigin-RevId: 684721071
The default name for the rules_jvm_external.maven rule is "maven". When not set, it defaults to "maven". For root modules also using rules_jvm_external, the name clash causes a warning:
```
DEBUG: $TMP/external/rules_jvm_external~/private/extensions/maven.bzl:154:14:
The maven repository 'maven' is used in two different bazel modules,
originally in '<my_workspace>' and now in 'protobuf'
```
Summarizing @shs96c in [1]:
> The common maven repo name allows rulesets to contribute to the user's JARs.
> However, this implies that maven is for the end user, not for transitive
> dependencies. If a ruleset needs private dependencies, it should use a custom
> namespace rather than the maven namespace.
Since protobuf is not contributing to user's JARs, we'll use a custom namespace. There's precedent for using a custom namespace for library modules:
- rules_jvm_external uses `rules_jvm_external_deps` instead of `maven`.
- rules_kotlin uses `kotlin_rules_maven` instead of `maven`.
[1]: https://github.com/bazel-contrib/rules_jvm_external/issues/916#issuecomment-1645527584Fixes#16839.
Closes#18641
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/18641 from jschaf:joe/protobuf-maven bd2c62f311
PiperOrigin-RevId: 684625084
The change is no-op for Bazel < 8, it always falls back to native providers.
When we cherry-pick --incompatible_autoload_externally to older Bazels, ProtoInfo
can be replaced with Starlark implementation, providing that users set the flag so that there is no second implementation exposed from Bazel.
PiperOrigin-RevId: 674561141
Bazel 6 falls back to native rules, because of ProtoInfo differences.
Bazel 7 is slightly degraded: Kythe flags don't work, DebugContext is left out from CcInfo and temporary files generated by the C++ compiler (but it's only useful for debugging).
Tests will be submitted in separate PRs.
PiperOrigin-RevId: 674030212
This simplifies upb by removing differences between google3 and OSS.
This also points upb at the protobuf license, instead of keeping a separate copy around for upb.
PiperOrigin-RevId: 669447145
This unfortunately makes the file significantly less compact. But given that Cider will automatically perform this formatting whenever you save, this seems like a fight we are not going to win.
PiperOrigin-RevId: 669430466
Adds new tests in `//compatibility` for detecting undesired breaking changes in the schema of the well-known types and `descriptor.proto` files, using the Buf breaking change detector, via [`rules_buf`](https://github.com/bufbuild/rules_buf/).
In order to keep things light-touch as far as maintenance goes, I have chosen to keep the integration as small and simple as possible. Some notes:
- Breaking change behavior can be granularly controlled via [`buf.yaml`](https://buf.build/docs/configuration/v1/buf-yaml#breaking).
- Bazel sandboxes us away from meaningful VCS information, so in order to pick a target to check for breaking changes against, a new variable is added to `protobuf_versions.bzl` that needs to be updated with changes in the release version.
- Breaking change detection is performed on a file-level, not a package-level, so migrating types across WKT files would constitute a breaking change. If this is not desired the behavior can be made to work on a package-level, though we need to do some more work as `buf_breaking_test` currently only accepts a single file descriptor set target for the `against` attribute.
Closes#17513
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/17513 from jchadwick-buf:buf-breaking cd46bb2c1e
PiperOrigin-RevId: 658624708
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
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
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
- Specifies bazel version for presubmits
- Set C++14 version (default is c++11 otherwise, which is unsupported)
- Update MODULE.bazel version + updater since publish-to-bcr can't handle constants and adds a duplicate version number
PiperOrigin-RevId: 633729225
They are not needed after the rules are move into protobuf repo.
Except for the reference to toolchain type, which is currently in rules_proto and can be moved after the implementation is moved into protobuf repo.
PiperOrigin-RevId: 622176865
Mike Kruskal
Protobuf Team Bot
Tony Liao
Joshua Haberman
Joe Schafer
Mike Kruskal
Zoey Greer
jchadwick-buf
zhangskz
Congcong Cai
Sandy Zhang
Keith Smiley
Alex Eagle