`unused_imports` redundant import check false positive with dev-dependency

[apoelstra]

I tried this code:

Cargo.toml

[package]
name = "unused_import_bug-2024-02"
version = "0.1.0"
edition = "2021"

[features]
default = ["std"]
std = ["bitcoin/std", "bitcoin/secp-recovery" ]

[dependencies]
bitcoin = { version = "0.31.0", default-features = false }

[dev-dependencies]
secp256k1 = {version = "0.28.0", features = ["rand-std"]}

src/main.rs

use bitcoin::secp256k1;

pub struct Thing(pub secp256k1::SecretKey);

fn main() {
    println!("Hello, world!");
}

If you compile this project with a recent nightly you will see the warning

   Compiling unused_import_bug-2024-02 v0.1.0 (/store/home/apoelstra/code/tmp/unused_import_bug-2024-02)
warning: the item `secp256k1` is imported redundantly
 --> src/main.rs:2:5
  |
2 | use bitcoin::secp256k1;
  |     ^^^^^^^^^^^^^^^^^^ the item `secp256k1` is already defined here
  |
  = note: `#[warn(unused_imports)]` on by default

This warning should not show up, and if it must show up, it should say where the compiler thinks the "redundant import" actually is. Because there is only a single import.

If you comment out the [dev-dependencies] part of Cargo.toml the error goes away.

[apoelstra]

Ok, what I think is going on is that when you run cargo test, all the dev-dependencies are implicitly imported, meaning that your necessary-for-cargo build imports become redundant.

If this is expected behavior then the error message needs to be much clearer.

[apoelstra]

Ok, I can mostly patch this by sticking #[cfg(not(test))] onto all of my imports, but for examples this doesn't work. It seems like examples pull in dev-dependencies but do not have cfg(test) set.

I can remove the import entirely, but then I am left with "example" code which does not actually compile outside of an example/ directory.

[petrochenkov]

All unused lints work after cfgs are expanded, this one is no different, so I'm going to close the issue.

The recent extension of unused_imports had some large effect on users in general, that is discussed in #121708 which is still open.