fix: make generated BPF toolchains analyzable on any CPU

[lsjostro]

Problem

declare_rustc_toolchains gives the generated BPF toolchain a linker select with no default branch, so the target cannot be analyzed for any CPU other than bpfeb/bpfel. This reproduces against the stock generated repo, no custom setup:

$ bazel cquery @default_rust_toolchains//rustc:all
ERROR: .../rustc/BUILD.bazel:5:25: configurable attribute "linker" in
@@rules_rs++toolchains+default_rust_toolchains//rustc:default_linux_x86_64_1_95_0_rust_toolchain_bpf
doesn't match this configuration. Would a default condition help?

Conditions checked:
  @@platforms//cpu:bpfeb
  @@platforms//cpu:bpfel

bazel build is unaffected because the toolchains are tagged manual, but manual does not exempt a target from cquery. Anything that analyzes a package rather than building it hits this — in our case target-determinator, which made CI fail on a change that built fine locally.

Fix

Both branches of the select held the same bpf_linker_label, so the select can be dropped for the label itself. No behaviour change: BPF targets are already gated by the toolchain's target_settings (@rules_rs//rs/toolchains:bpf_targets), which is the right place for that restriction.

"//conditions:default": None is not an option here — rust_toolchain rejects it with "When rust_toolchain.linker_preference == \"rust\", a rust_toolchain.linker must be provided".

Verification

With this change, bazel cquery @default_rust_toolchains//rustc:all completes successfully. Verified via local_path_override from a workspace that registers the generated toolchains; its Rust targets build and its tests pass unchanged.

I have no BPF targets to exercise, so the BPF path itself is only covered by your CI.

Related

Two other selects in the same macro have no default branch (target_triple on the non-BPF toolchain, and the {name}_rust_std alias). Those only bite when the macro is called from a workspace package, and a naive default there would turn a loud analysis error into a silently wrong target triple, so I have left them alone — happy to file an issue with the details if that is useful.

[dzbarsky]

oh, good idea, thank you!