Fix builds for Bazel >= 9.0.0-pre.20250714.1

[mbland]

Description

Resolves the following last_green CI build error resulting from the following changes appearing in Bazel 9.0.0-pre.20250714.1:

• https://buildkite.com/bazel/rules-scala-scala/builds/5701#019839bb-2124-4600-a91c-ece2eedc46fa/122-218
• https://github.com/bazelbuild/bazel/pull/26493/files#diff-47a01c886ef9dc97641591dd4dd08157ef1414496979456380830acc9f694e65R67-R72
• https://github.com/bazelbuild/bazel/pull/26493/files#diff-47a01c886ef9dc97641591dd4dd08157ef1414496979456380830acc9f694e65R101

$ USE_BAZEL_VERSION=9.0.0-pre.20250714.1 bazel test //src/... //test/...

ERROR: scala/scala_maven_import_external.bzl:145:29:
  An error occurred during the fetch of repository
  '+scala_deps+scala_proto_rules_scalapb_protoc_gen_2_12_20':

  Traceback (most recent call last):
    File "scala/scala_maven_import_external.bzl", line 145, column 29,
    in _jvm_import_external_impl
      (repository_ctx.attr.visibility or

Error: unknown attribute visibility

ERROR: no such package
    '@@+scala_deps+scala_proto_rules_scalapb_protoc_gen_2_12_20//':
    unknown attribute visibility

ERROR: test/proto/custom_generator/BUILD.bazel:44:22:
  //test/proto/custom_generator:scalapb_worker_deps_provider depends on
  @@+scala_deps+scala_proto_rules_scalapb_protoc_gen_2_12_20//:scala_proto_rules_scalapb_protoc_gen_2_12_20
  in repository
  @@+scala_deps+scala_proto_rules_scalapb_protoc_gen_2_12_20
  which failed to fetch.

  no such package
  '@@+scala_deps+scala_proto_rules_scalapb_protoc_gen_2_12_20//':
  unknown attribute visibility

ERROR: Analysis of target
  '//test/proto/custom_generator:scala_proto_deps_toolchain_def' failed;
  build aborted: Analysis failed

Another problem remains, but it appears to be on Bazel's end per bazelbuild/bazel#26579 (stemming from bazelbuild/bazel#26477):

$ USE_BAZEL_VERSION=9.0.0-pre.20250714.1 bazel test //src/... //test/...

ERROR: error loading package '@@bazel_tools//src/main/protobuf':
  Unable to find package for
  @@[unknown repo 'grpc-java' requested from @@bazel_tools]//:java_grpc_library.bzl:

  The repository '@@[unknown repo 'grpc-java' requested from @@bazel_tools]'
  could not be resolved:
  No repository visible as '@grpc-java' from repository '@@bazel_tools'.

ERROR: src/java/io/bazel/rulesscala/coverage/instrumenter/BUILD:3:12:
  error loading package '@@bazel_tools//src/main/protobuf':
  Unable to find package for
  @@[unknown repo 'grpc-java' requested from @@bazel_tools]//:java_grpc_library.bzl:

  The repository '@@[unknown repo 'grpc-java' requested from @@bazel_tools]'
  could not be resolved:
  No repository visible as '@grpc-java' from repository '@@bazel_tools'.
  and referenced by
  '//src/java/io/bazel/rulesscala/coverage/instrumenter:instrumenter'

ERROR: Analysis of target '//test/aspect:scala_junit_test' failed;
  build aborted: Analysis failed

Neither of these errors occurred when building with Bazel 9.0.0-pre.20250710.1.

The scala/private/extensions/dev_deps.bzl update eliminates the warning:

DEBUG: scala/scala_maven_import_external.bzl:80:14:
  'jar_sha256' is deprecated. Please use 'artifact_sha256'

Motivation

It seems prudent to address this last_green failure separately from bumping dependency versions before releasing v7.1.0. We'll have to wait for an upstream fix for bazelbuild/bazel#26579, however. Once it appears, though, the last_green build should succeed again, with this change already in place.

Also, ostensibly, repository_ctx.attr.visibility was never a valid value for package(default_visibility = ...). Removing it seems more correct than getattr(repository_ctx, "visibility", []).

[mbland]

@simuons I ran out of time to do the version bump PR today; will file that tomorrow.

A few notes for @Wyverald regarding the issues with Bazel 9.0.0-pre.20250714.1 described in this PR:

Since you're the author of bazelbuild/bazel#26493, I'd appreciate if you'd double-check my assertion at the end of the PR description that:

repository_ctx.attr.visibility was never a valid value for package(default_visibility = ...).

FYI, tools/build_defs/repo/jvm.bzl still contains a 'repository_ctx.attr.visibility' reference as of 3be8101 from 2025-07-23 in the same package(default_visibility = ...) context as the reference removed here.

Also, bazelbuild/bazel#26579 from has bitten the last_green build for rules_scala as well. In addition to the example from the PR description, you can see the missing grpc-java error in the last_green build for this PR.

[simuons]

Thanks, @mbland! As always it's a real pleasure to see such a thorough analysis.

[Wyverald]

repository_ctx.attr.visibility was never a valid value for package(default_visibility = ...).

It was in fact valid. Repo rules were just like regular rules, so they inherited a bunch of default attributes like tags, visibility, deprecation, testonly, etc. But none of these attributes actually do anything (except that the repo rule impl can read their values using rctx.attr.tags...).

When I made the change to decouple repo rules from build rules, it seemed natural to remove these legacy default attrs. But it would indeed break some really weird use cases like the one you fixed -- which I think should be rare enough.

[mbland]

@Wyverald Thanks for the clarification. Even if it was previously technically valid, it seems removing it here is at least as valid.

I hope this use case was indeed rare, but this file was originally copied from some version of tools/build_defs/repo/jvm.bzl from within Bazel, and the current jvm.bzl within Bazel still contains a reference to repository_ctx.attr.visibility. I don't know if that file should be updated or deleted, but I would've expected one of Bazel's own tests to have broken.

[Wyverald]

That's true, jvm_import_external is broken. IMO all the bundled JVM-related repo rules in bazel_tools should be deleted, since rules_jvm_external exists, and Starlarkification means the dependency on rules_java should ideally be removed anyway.

A while back I did a GitHub search, and saw there were still quite a few usages out in the wild, so I didn't immediately do the deletion. But maybe it's time.