Incorrect dependency feature set used for same-target bindep dependency compilation

[rvolosatovs]

Full example available at https://github.com/rvolosatovs/musl-bindep-feature-bug

It appears that in presence of the same dependency specified multiple times with different feature sets within a workspace it is only compiled once when bindeps are used.

I tried this top-level Cargo.toml:

[package]
name = "musl-bindep-feature-bug"
version = "0.1.0"
edition = "2021"

[dependencies]
rsa = { workspace = true }

# This causes build failure with `cargo build --target x86_64-unknown-linux-musl`:
dep = { version = "0.1.0", path = "crates/dep", artifact = "bin", target = "x86_64-unknown-linux-musl" }
# This would cause a build failure with `cargo build --target wasm32-wasi`
#dep = { version = "0.1.0", path = "crates/dep", artifact = "bin", target = "wasm32-wasi" }
# This would fix the error:
#dep = { version = "0.1.0", path = "crates/dep" }

[workspace.dependencies]
rsa = { version = "0.7.2", default-features = false }
# This would fix the error:
#rsa = { version = "0.7.2" }

With following subcrate Cargo.toml:

[package]
name = "dep"
version = "0.1.0"
edition = "2021"

[dependencies]
rsa = { version = "0.7.2" }
# This would fix the error:
#rsa = { workspace = true }
#rsa = { version = "0.7.2", default-features = false }

I expected to see this happen: successful compilation with cargo build --target x86_64-unknown-linux-musl

Instead, this happened:

   Compiling rsa v0.7.2
error[E0599]: the method `gen_prime` exists for mutable reference `&mut R`, but its trait bounds were not satisfied
   --> /home/rvolosatovs/.cargo/registry/src/github.com-1ecc6299db9ec823/rsa-0.7.2/src/algorithms.rs:100:26
    |
100 |             *prime = rng.gen_prime(todo / (nprimes - i));
    |                          ^^^^^^^^^ method cannot be called on `&mut R` due to unsatisfied trait bounds
    |
    = note: the following trait bounds were not satisfied:
            `R: rand::rng::Rng`
            which is required by `R: RandPrime`
            `&mut R: rand::rng::Rng`
            which is required by `&mut R: RandPrime`
help: consider restricting the type parameter to satisfy the trait bound
    |
57  | ) -> Result<RsaPrivateKey> where R: rand::rng::Rng {
    |                            +++++++++++++++++++++++

error[E0599]: the method `gen_biguint_below` exists for mutable reference `&mut R`, but its trait bounds were not satisfied
   --> /home/rvolosatovs/.cargo/registry/src/github.com-1ecc6299db9ec823/rsa-0.7.2/src/internals.rs:144:17
    |
144 |         r = rng.gen_biguint_below(key.n());
    |                 ^^^^^^^^^^^^^^^^^ method cannot be called on `&mut R` due to unsatisfied trait bounds
    |
    = note: the following trait bounds were not satisfied:
            `R: rand::rng::Rng`
            which is required by `R: RandBigInt`
            `&mut R: rand::rng::Rng`
            which is required by `&mut R: RandBigInt`
help: consider restricting the type parameter to satisfy the trait bound
    |
134 | ) -> (BigUint, BigUint) where R: rand::rng::Rng {
    |                         +++++++++++++++++++++++

For more information about this error, try `rustc --explain E0599`.
error: could not compile `rsa` due to 2 previous errors

Note, that the issue does not happen if compilation is done for the native triple.
This issue also does not occur if the subcrate is turned into a regular dependency, as opposed to a bindep.

Note, that build for wasm32-wasi would fail as well, but only if bindep target is changed to wasm32-wasi

Meta

rustc --version --verbose:

rustc 1.67.0-nightly (c97b539e4 2022-11-30)
binary: rustc
commit-hash: c97b539e408ea353f4fde2f9251d598291fec421
commit-date: 2022-11-30
host: x86_64-unknown-linux-gnu
release: 1.67.0-nightly
LLVM version: 15.0.4

With RUST_BACKTRACE=1 output is identical to the log above

[weihanglo]

Thank you for the report and the reproducer! I believe it is more or less the same as #10837. The possible root cause was described in #10837 (comment).

Closing as it is a duplicate. If this is wrong for you, we can consider re-open it.