Binary dependency is never built if specified with both optional and target keys

[bstrie]

Problem

For convenience I have also uploaded the failing code here: https://github.com/bstrie/bindeperror2

For the following code:

# Cargo.toml
[package]
name = "mycrate"
version = "0.0.0"
edition = "2021"

[dependencies]
mybindep = { path = "mybindep", artifact = "bin", optional = true, target = "x86_64-unknown-linux-gnu" }

[features]
default = ["mybindep"]

// src/main.rs
fn main() {
    env!("CARGO_BIN_FILE_MYBINDEP");
}

# mybindep/Cargo.toml
[package]
name = "mybindep"
version = "0.0.0"
edition = "2021"

// mybindep/src/main.rs
fn main() {}

I expected this code to build. However, cargo build produces the following:

 > cargo build
   Compiling mycrate v0.0.0 (/home/ben/code/scrap/bindeperror2)
error: environment variable `CARGO_BIN_FILE_MYBINDEP` not defined
 --> src/main.rs:2:5
  |
2 |     env!("CARGO_BIN_FILE_MYBINDEP");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this error originates in the macro `env` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `mycrate` due to previous error

As we can see from the output, it is not merely that the environment variable is missing; only mycrate is ever built, and mybindep is skipped.

Note that mybindep is an optional dependency, but is specified as a default feature.

In addition, neither cargo build --features mybindep nor cargo build --all-features will result in mybindep being built.

The following causes the code to compile:

- mybindep = { path = "mybindep", artifact = "bin", optional = true, target = "x86_64-unknown-linux-gnu" 
+ mybindep = { path = "mybindep", artifact = "bin", optional = true }

Furthermore, with this (along with removing the default feature) we can observe that cargo build --features mybindep and cargo build --all-features now functions as expected. Leaving the target key and removing the optional key also causes the code to build. It is the presence of both these keys simultaneously that results in the issue.

cc @Byron

Version

cargo 1.61.0-nightly (109bfbd 2022-03-17)
release: 1.61.0-nightly
commit-hash: 109bfbd055325ef87a6e7f63d67da7e838f8300b
commit-date: 2022-03-17
host: x86_64-unknown-linux-gnu
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1m)
os: Pop!_OS 21.10 (impish) [64-bit]

[bstrie]

@weihanglo Thanks for working on this, even if #11183 didn't quite work out. :)

[weihanglo]

Oops. Really? Both #11183 (checkout this commit 810cbad) or the patch in the PR description of #11331 work for me with your example. Maybe my assumption was wrong. Could you try it again?

Anyhow, I'll continue investigating a solution like patch from #11331, but need more refactors.

[bstrie]

Er, sorry, I meant to refer to #11131 as the patch to address this that didn't work out and was reverted.