bazelbuild / bazel

a fast, scalable, multi-language and extensible build system
https://bazel.build
Apache License 2.0
23.27k stars 4.08k forks source link

[7.4.0] programmatic error in the cc_shared_library rule #24063

Open illicitonion opened 1 month ago

illicitonion commented 1 month ago

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.

c1183081083d01cbd088c9fa352812a5f5d4408d

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 commented 4 weeks ago

@pzembrod @oquenchil

meteorcloudy commented 4 weeks ago

Does this also happen to Bazel@HEAD?

meteorcloudy commented 4 weeks ago

@fmeum Are you looking into a fix?

fmeum commented 4 weeks ago

I am

fmeum commented 4 weeks ago

@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 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

@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 https://github.com/bazelbuild/bazel/pull/24087.

oquenchil commented 4 weeks ago

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 https://github.com/bazelbuild/bazel/commit/68ee1e4169c99645c803bda79eb3f1e198d8b055

Maybe that's relevant and it can help.