[7.4.0] programmatic error in the cc_shared_library rule

[illicitonion]

Description of the bug:

rules_rust CI picks up latest Bazel releases. Since 7.4.0 was released, our CI has been failing with:

(18:32:25) ERROR: /Users/buildkite/builds/bk-macos-pln3-ds9s/bazel/rules-rust-rustlang/test/cc_shared_library/BUILD.bazel:19:18: in cc_shared_library rule //test/cc_shared_library:shared:
--
  | Traceback (most recent call last):
  | File "/virtual_builtins_bzl/common/cc/cc_shared_library.bzl", line 670, column 114, in _cc_shared_library_impl
  | File "/virtual_builtins_bzl/common/cc/cc_shared_library.bzl", line 530, column 44, in _filter_inputs
  | File "/virtual_builtins_bzl/common/cc/cc_shared_library.bzl", line 79, column 28, in _sort_linker_inputs
  | File "/virtual_builtins_bzl/common/cc/cc_shared_library.bzl", line 55, column 9, in _programmatic_error
  | Error in fail: Your build has triggered a programmatic error in the cc_shared_library rule. Please file an issue in https://github.com/bazelbuild/bazel : @//test/cc_shared_library:c_lib,@//test/cc_shared_library:rust_lib vs 3

See https://buildkite.com/bazel/rules-rust-rustlang/builds/12498#0192ba36-aa5a-49d7-af36-0c85e2c50257 for an example.

Repro by cloning https://github.com/bazelbuild/rules_rust at 113439296e4c264aa4ac7fe49f35eb52f0c95dcb and running: USE_BAZEL_VERSION=7.4.0 bazel test test/cc_shared_library/...

7.3.2 passes cleanly.

Which category does this issue belong to?

C++ Rules

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Clone https://github.com/bazelbuild/rules_rust at 113439296e4c264aa4ac7fe49f35eb52f0c95dcb and run: USE_BAZEL_VERSION=7.4.0 bazel test test/cc_shared_library/...

Which operating system are you running Bazel on?

Any

What is the output of bazel info release?

release 7.4.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

origin	git@github.com:bazelbuild/rules_rust.git (fetch)
origin	git@github.com:bazelbuild/rules_rust.git (push)
113439296e4c264aa4ac7fe49f35eb52f0c95dcb

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

c118308

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

cc @fmeum

[fmeum]

@pzembrod @oquenchil

[meteorcloudy]

Does this also happen to Bazel@HEAD?

[meteorcloudy]

@fmeum Are you looking into a fix?

[fmeum]

I am

[fmeum]

@meteorcloudy With last_green, I get a different failure:

ERROR: Error computing the main repository mapping: at /private/var/tmp/_bazel_fmeum/1be3cb90b5e931599cbed59281fc8ffa/external/bazel_tools/tools/cpp/cc_configure.bzl:18:6: Label '@@rules_cc//cc/toolchains:toolchain_config_utils.bzl' is invalid because 'cc/toolchains' is not a package; perhaps you meant to put the colon here: '@@rules_cc//cc:toolchains/toolchain_config_utils.bzl'?

[fmeum]

This is happening because @rust_darwin_aarch64__aarch64-apple-darwin__stable_tools//:rust_toolchain (on my MacBook) contributes a LinkerInput (which was previously ignored since it only contains linkopts), but isn't visited by the aspect that accumulates the transitive dependencies for the topological sort as it doesn't advertise CcInfo. You could argue it's not a regression, but surfaces a deeper issue that has been present all along. :-)

@oquenchil Did you factor in LinkerInputs contributed by toolchains when you wrote cc_shared_library? Do you happen to have an idea how they could be accommodated?

[peakschris]

I am also seeing this issue on a pure (I think) C++ build. 7.4.0rc2 is OK, 7.4.0 has the issue.

[fmeum]

@meteorcloudy We'll look for a fix for Bazel@HEAD and Bazel 8, but we should definitely revert this for 7.4.0. I sent #24087.

[oquenchil]

Fabian I don't remember anything related to LinkerInputs in toolchains that I can give you as context. I think I didn't add anything specific since back then because when I wrote it toolchains didn't have objects of the LinkerInput class (or any C++ provider), not sure if that's not the case anymore.

The cc_shared_library aspect only propagated via the CcInfo provider. The actual linker inputs from the toolchains were added to actions but as as raw files, not wrapped in the LinkerInput class. Adding the raw toolchain files has always been done automatically behind the cc_common API without having to do it explicitly.

I can tell you though that Mai added an API for aspects propagated to toolchains back in July 68ee1e4

Maybe that's relevant and it can help.