deps: updates for bazel 8 compatibility

[rickeylev]

Various changes to support Bazel 8. An important note is dependencies have forced
us to change the versions of Bazel we support.

Summary of changes:

• rules_cc 0.0.14: Releases after 0.0.9 have some Bazel 8 fixes, but also broke
  some things. Things seemed to have settled by 0.0.14.
• protobuf 29.0-rc1: Technically 28.0 works, however:
  1. 29.0-rc1 is coming via a transitive dependency anyways, and
  2. In protobuf 28.0, compile warnings are treated as errors, which our Debian CI
     respects (and thus fails), while other platforms ignore.
• stardoc 0.7.1: Fixes an issue with Bazel 8 and stardoc using empty globs.
• Bazel 7.4 is now the minimum supported Bazel version. This requirements comes via
  dependencies.
• Drop Bazel 6 bzlmod support. This requirement comes via dependencies.
• Add a presubmit job for last_rc Bazel (currently the 8.x RC).
• Use a local patch so Gazelle works with Bazel 8. This can be removed
  once native.sh_binary reference in def.bzl blocks Bazel 8 integration bazel-contrib/bazel-gazelle#1959 is fixed and released.
• Fix a $(rpathlocation) call in bootstrap tests.
• Update bzl_library deps after upgrading deps: the set of targets that provide
  bzl sources changed in rules_cc and protobuf in these newer versions.

Sorting this all out and finding the right combination of dependency versions was
fairly involved. The details of that are in
#2378.

Work towards #2378, #2387

[aignas]

The only real question is the defs.bzl usage from rules_cc. I remember there was a PR here #2293, but I can still find usage of defs.bzl in our git repo in this PR.

[aignas]

This is a little bit mysterious. Will we be able to remove it at some point?

[rickeylev]

I updated the comment to explain why it's here.

The example sets --java_runtime_version=remotejdk_11, which is broken with Bazel 8 until rules_java 8.3.

[aignas]

And if I remember correctly this is only to make the coverage collection not depend on system Java. So technically all of our consumers will need to add this dep if they want coverage.

[aignas]

Should we remove the usage of defs.bzl, maybe that will fix it?

$ git grep "defs.bzl.*cc" **/*.bzl
python/private/common_bazel.bzl:load("@rules_cc//cc:defs.bzl", "CcInfo", "cc_common")
python/private/hermetic_runtime_repo_setup.bzl:load("@rules_cc//cc:defs.bzl", "cc_import", "cc_library")
python/private/local_runtime_repo_setup.bzl:load("@rules_cc//cc:defs.bzl", "cc_library")
python/private/py_executable.bzl:load("@rules_cc//cc:defs.bzl", "cc_common")
python/private/runtime_env_toolchain.bzl:load("@rules_cc//cc:defs.bzl", "cc_library")
python/private/whl_filegroup/whl_filegroup.bzl:load("@rules_cc//cc:defs.bzl", "cc_library")
tests/support/cc_toolchains/fake_cc_toolchain_config.bzl:load("@rules_cc//cc:defs.bzl", "cc_common")

[rickeylev]

Hm, yeah, removing defs.bzl might fix this (depends on if the more specific targets properly specify their bzl_libraries 😅 )

I wrote this comment before (1) I unwound the whole defs.bzl removing cc_proto_library thing, and (2) I gave up trying to make bazel 6 with bzlmod work.

I've updated the comment to better reflect this.

[aignas]

Ah, I read the PR I linked - I somewhat think that maybe we could couple the PRs together and see if we can remove the extra protobuf deps that we had to add. rules_rust in our examples looks extremely concerning.

[aignas]

nit: I think we should also resolve the following warnings in the rules_python repo:

WARNING: For repository 'bazel_features', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'platforms', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'rules_proto', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off
WARNING: For repository 'com_google_protobuf', the root module requires module version [email protected], but got [email protected] in the resolved dependency graph. Please update the version in your MODULE.bazel or set --check_direct_dependencies=off

[rickeylev]

The only real question is the defs.bzl usage from rules_cc. I remember there was a PR here #2293, but I can still find usage of defs.bzl in our git repo in this PR.

Yeah, this whole part is a mess. Our usage of rules_cc/defs.bzl is OK, sort of -- deprecated, but not broken, per-se. The problem comes when other dependencies come into play. Basically, rules_cc removed a symbol (cc_proto_library) from defs.bzl. However, some things still loaded that symbol, so fixes were sent out. While all this is going on, various versions of modules were released with various problems with Bazel 6, Bazel 8, and/or the removal of that symbol.

So, our usage of rules_cc/defs.bzl is only a problem depending on what combinations of what dependencies you end up with. Us switching off rules_cc/defs.bzl makes it less likely to occur (since we wouldn't be a potential cause of loading that file when an incompatible dependency is being used).

re: coupling this PR and the defs.bzl removal: Well, I was going to say this PR has been a chore and I don't want to expand it's scope, but now CI is failing with yet-another-rules-cc-defs.bzl looking failure. So maybe it'll be easier to put those in one PR. I'll have a look at that failure to see which is gonna be easier.

re: module versions:

• bazel_features and platforms are coming from dev dependencies, I think. I don't see those warnings when building the bzlmod example.
• rules_proto, protobuf: I've updated their versions

[rickeylev]

CI is failing with yet-another-rules-cc-defs.bzl looking failure

The failure was: Bazel 9 with workspace was failing because Bazel 9 removes native.cc_proto_library

I've "fixed" this by removing the bazel-in-bazel integration tests for rolling, A bzlmod invocation is OK because it uses protobuf 29.0-rc1+, which has a fix for that. However, Bazel 9 with workspace is using an earlier protobuf version. I tried updating that, but it looks like it has further dependencies that need to be setup and/or upgraded.

Given that Bazel 9 is a ways off, I think it makes sense to temporarily disable that test. I'll need some time to try and figure out the necessary WORKSPACE updates that need to be made.

[aignas]

Thanks for all of this untangling of the mess. This is sure a bumpy one - I remember bazel 7 not being nearly as bad.

[aignas]

Approving since the CI is green and we can go bit by bit fixing all of the remaining things. My main concerns are:

• Can we remove some of the deps added here by switching away from rules_cc:defs.bzl.
• The java flag in the bazelrc was there for bazel coverage support and I don't understand if we can safely remove it and the coverage will just work or we have to document it to the example code readers, that they need to have that dep as well?

Regardless of the outcome of the above, this is moving in the right direction.