`artifact = "bin"` build-dependency does not provide `CARGO_BIN_FILE_*` env vars for registry crates in build scripts

[NikoPit]

Problem

Cargo's unstable artifact dependencies appear to behave differently for path/workspace
dependencies vs registry dependencies when used from a build script.

According to the artifact dependencies documentation, build-dependencies with
artifact = "bin" should make artifact paths available to build.rs via
CARGO_BIN_FILE_* environment variables.

In my local workspace/path setup, this works as expected: the build script sees both
CARGO_BIN_FILE_ROXY_LOADER and CARGO_BIN_FILE_ROXY_LOADER_roxy-loader.

However, after publishing the same crate to crates.io and consuming it as a registry
dependency, the build script no longer receives any CARGO_BIN_FILE_* variables, even
though the published manifest still contains the artifact build-dependency.

Current behavior:

• path/workspace dependency: build.rs receives CARGO_BIN_FILE_*
• registry dependency: build.rs does not receive CARGO_BIN_FILE_*
• build script fails because the artifact path is missing

Expected behavior:

• registry dependencies should behave the same as path dependencies here, or the
  limitation should be documented clearly if this is unsupported

Steps

1. Create crate producer with a binary target.
2. Create crate consumer with:
   • cargo-features = ["artifact-dependencies"]
   • .cargo/config.toml:

     [unstable]
     bindeps = true

   • a build-dependency on producer:

     [build-dependencies]
     producer = { version = "...", artifact = "bin", target = "x86_64-unknown-uefi" }

3. In consumer/build.rs, print all CARGO_BIN_FILE_* environment variables and try
   to read the producer artifact path.
4. Build consumer while producer is used as a local path/workspace dependency.
   • CARGO_BIN_FILE_* variables are present.
5. Publish both crates and switch consumer to use the published producer from
   crates.io.
6. Build consumer again.
   • CARGO_BIN_FILE_* variables are no longer present in build.rs.
   • the build script fails because the artifact path is missing

Possible Solution(s)

Either:

1. Make registry dependencies behave the same as path/workspace dependencies for
   artifact build-dependencies in build scripts, or
2. Document that this combination is currently unsupported/limited for registry
   crates.

From the outside, this looks like Cargo is preserving the artifact dependency in the
published manifest, but not propagating the corresponding CARGO_BIN_FILE_*
environment variables to build.rs when the dependency comes from the registry.

Notes

I verified that the normalized published Cargo.toml still contains the artifact
dependency. For example:

[build-dependencies.roxy-loader]
version = "0.1.1-alpha.1"
artifact = ["bin"]
target = "x86_64-unknown-uefi"

I also verified two different behaviors:

Path/workspace case:

• build.rs receives:
  • CARGO_BIN_FILE_ROXY_LOADER=...
  • CARGO_BIN_FILE_ROXY_LOADER_roxy-loader=...

Registry case:

• build.rs receives no CARGO_BIN_FILE_* variables at all
• only normal variables such as HOST and TARGET are visible

Example registry-case stderr from build.rs:

HOST=x86_64-unknown-linux-gnu
TARGET=x86_64-unknown-linux-gnu
thread 'main' panicked: Roxyloader artifact not found

This suggests the issue is not manifest normalization removing artifact = "bin", but
Cargo not exposing the artifact env vars in the registry dependency case.

Version

cargo 1.95.0-nightly (fe2f314ae 2026-01-30)
release: 1.95.0-nightly
commit-hash: fe2f314aef06e688a9517da1ac0577bb1854d01f
commit-date: 2026-01-30
host: x86_64-unknown-linux-gnu
libgit2: 1.9.2 (sys:0.20.3 vendored)
libcurl: 8.15.0-DEV (sys:0.4.83+curl-8.15.0 vendored ssl:OpenSSL/3.5.4)
ssl: OpenSSL 3.5.4 30 Sep 2025
os: NixOS 26.5.0 [64-bit]