Distributed ThinLTO rlib CcInfo lacks shared non-LTO backends for static C++ tests

[Spikhalskiy]

Summary

Distributed ThinLTO currently opts rlib and lib crates in, but the CcInfo they export does not provide the shared non-LTO backends that Bazel requires when a statically linked C++ test uses the shared-backend ThinLTO mode.

Reproduction

Using the rules_rust revision bundled by rules_rs v0.0.107 (9ec12231debd8a929faafa0c014a8a897e4899c0), enable:

--features=thin_lto
--features=thin_lto_linkstatic_tests_use_shared_nonlto_backends

Then build a static cc_test or cc_binary that transitively depends on a Rust rlib. Bazel analysis fails before actions run:

Statically linked test target requires non-LTO backends for its library inputs,
but library input ... does not specify shared_non_lto_backends

The failing LibraryToLink contains the rlib object and pic_lto_compilation_context, but its pic_shared_non_lto_backends is empty.

Why this matters

The shared non-LTO backend feature avoids rerunning ThinLTO indexing and codegen for every static C++ test. Disabling it avoids this check but materially increases build work; disabling thin_lto loses ThinLTO entirely. The public //rust/settings:lto setting does not control this path because distributed ThinLTO is selected from the C++ thin_lto feature.

Expected behavior

rlib/lib crates that participate in distributed ThinLTO should either:

1. provide the shared non-LTO backends required by their exported CcInfo, or
2. be excluded from distributed ThinLTO when that provider cannot be produced.

An optional public setting to choose eligible crate types would let users make this tradeoff deliberately, but the provider inconsistency itself appears to be a correctness bug.

Workaround

diff --git a/rust/private/rustc.bzl b/rust/private/rustc.bzl
--- a/rust/private/rustc.bzl
+++ b/rust/private/rustc.bzl
@@ -910,7 +910,7 @@ def _supports_distributed_thin_lto(ctx, toolchain, crate_info):
     """Whether `crate_info` can participate in distributed ThinLTO."""
     return (
-        crate_info.type in ("bin", "lib", "rlib") and
+        crate_info.type == "bin" and
         toolchain.target_arch not in ("wasm32", "wasm64") and
         not toolchain._bootstrapping and
         not is_no_std(ctx, toolchain, crate_info.is_test)
    )

[dzbarsky]

Thanks for filing this, I wasn't even aware of thin_lto_linkstatic_tests_use_shared_nonlto_backends. Lots of hidden feature :)
Let me play around and see what we can do!

[dzbarsky]

@Spikhalskiy

Thanks again for the report! I traced this to rules_cc: your rules_rust revision already supplies the PIC objects and LTO context correctly, but cc_common.create_library_to_link wasn’t generating pic_shared_non_lto_backends.

The fix is already upstream in rules_cc commit 4591082a. Updating to a revision containing that commit, or backporting it, should let you remove the workaround and keep distributed ThinLTO enabled for Rust libraries. No rules_rust implementation change is needed.

If you were to use @llvm from hermeticbuild/hermetic-llvm, there’s also pending PR #734 to declare both shared-backend features so Bazel recognizes those flags. Your reported error indicates your current toolchain already recognizes the feature.

I’m adding regression coverage in:

• rules_cc #868: verifies PIC backend generation and that two static C++ tests reuse the same native object.
• rules_rust #52: exercises static C++ tests and binaries consuming Rust libraries with shared backends.

I reproduced the original failure and verified that a static C++ test calling Rust compiles, links, and runs successfully with the fixes.

[Spikhalskiy]

Thank you for a quick attention to the issue!
rules_cc 0.2.23 has not reached the Bazel Central Registry yet.
When it does, I will pick it up and test if it allows us to get rid of the workaround.