Allow artifact target set for build-std

[197g]

Adds unstable flag build-std-targets.

The intended use is for projects that mix a Tier 1/2 target as a host with a Tier 3 target in an artifact dependency, which is then deployed at runtime. For instance, x86-64-*-linux and bpfeb-unknown-none, or a supported host with a custom hardware profile given by json.

In these cases it is unlikely that all std libraries should be built from scratch. Additionally, the list of std builds are not only those given as direct targets on the command line but rather discovered by target specifications on artifact dependencies that are embedded to a host loader etc.

The previous state discovered the set of std-builds through the target list of the CLI but never dynamically within the crate graph. The unit graph would then try to access the std build for kinds that were not generated, resulting in panics in unit dependency planning.

What does this PR try to resolve?

Consider a Linux eBPF project in full Rust. We're building two binaries here, firstly a Linux host binary that interacts with the kernel from within x86_64 user space, secondly a binary in the kernel's eBPF language that compiles to a small module uploaded into the kernel at runtime. A nice setup would declare the latter as an artifact dependency of the former to either bundle it into the binary via includes or reference it an asset mechanism otherwise. Since bpfeb-unknown-none does not ship with std we must built it.

cargo-features = ["per-package-target"]

[package]
name = "loader"
version = "0.0.0"
edition = "2024"
default-target = "x86_64-unknown-linux-gnu"

[dependencies]
xdp = { package = "ebpf-xdp", version = "0.0", path = "../xdp", artifact = "bin", target = "bpfeb-unknown-none" }

cargo-features = ["per-package-target"]

[package]
name = "ebpf-xdp"
version = "0.0.0"
edition = "2024"
forced-target = "bpfeb-unknown-none"

[dependencies]
# e.g. aya-ebpf = "0.1.1"

Here's the cargo configuration we can use after this PR:

[unstable]
build-std = ["core", "alloc", "compiler_builtins", "panic_abort"]
bindeps = true
build-std-targets = ["bpfeb-unknown-none"]

[build]
target = "x86_64-unknown-linux-gnu"

Note the bpf target applies only the artifact, everything else depends still on the users intended host profile and should not get a fixed target (just using a default).

To address such a project setup cargo should do at least two things:

1. collect a list of targets for which core/alloc is supposed be built, that is independent from the list of targets it is invoked with on the CLI.
2. at runtime while iterating package units, find CompileKinds that match a need for having their std built and add the std units.

In the implementation, step (2.) finds its information of targets based on the target attribute of an artifact dependency. It does not interact with forced-target. This may be a debatable choice depending on how these two features are seen in relation to each other. Should a forced target also propagate as a default to the target attribute, overriding the 'host' meaning that its omission otherwise implies?

How to test and review this PR?

Test with cargo infrastructure to be added, see the above crate setup.

In the released cargo this gets an error in all operations:

$ cargo check
thread 'main' panicked at src/tools/cargo/src/cargo/core/compiler/unit_dependencies.rs:180:34:
no entry found for key
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

What remains to be tested is all interactions with different settings of [build.target] and command line overrides. Guidance on testing the absence of a std build would be appreciated, i.e. would all information appear appropriately in the generated unit graph as a metadata output?

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ehuss]

Similar to the comment at #15670 (comment), the design for build-std is in active flux. At this time I would prefer to not be making changes until the design is settled.

[197g]

That's fine. We can close this PR until a time it is settled, it's available for future reference. I hope the use-case details help with the direction of the eventual design. Edit: keeping the branch of course.