You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IMO it should be based on the --extern args provided to rustc, and should not ignore "for-side-effects-only" imports now that we can do use some_crate as _;
Reacted by mark, Steven Fackler, Jeremy Fitzhardinge, Dabo, Mehmet Akif DERE, Felipe S. S. Schneider and nielsle
This might have issues with adding dependencies-of-dependencies to force specific versions (I'm not sure how common that pattern is, and I guess they could be treated as "for-side-effects-only" imports as @cramertj mentions above).
In a project, I was just adding such (originally-)transitive dependencies to get a -Z minimal-versions build working. At least before "unused_extern_crates" is changed to default to "warn", perhaps an allow=unused flag could be supported on the Cargo.toml dependency itself, like the #[allow(some_lint)] attribute in code?
I agree both that use some_crate as _; should not trigger the unused_extern_crate lint (should not be treated as unused) and with the concern for the use-case raised by @Nemo157. Needing to add use some_crate as _; for each of these originally-transitive dependencies is more cumbersome, when just wanting to guide cargo's dependency resolution, where nothing really needs to be imported as far as rustc is concerned. Note also in my case, using the [patch] section of Cargo.toml didn't work for the such resolution adjustment.
We'd also have to make sure that if you have, say, two binaries in a crate, and Cargo.toml lists a dependency that is only used by one of them, compiling the other shouldn't generate a warning.
@jonhoo IMO that's a bug in cargo that it doesn't allow specifying per-build-target dependencies (or maybe it does, in which case users should do that).
@cramertj yeah, I agree, the real solution would be to have per-target dependencies, but sadly that's not something we have yet. There's some discussion in rust-lang/cargo#1982 on how we may add support for dependencies for binary targets, which would go a long way, but that has been open for a while. Until we get support for that though, we'd have to make sure that the lint doesn't erroneously give a warning in those cases.
@jonhoo It seems fine to me to silence those cases using use X as _;. They are unused external crates, and it's wrong for them to be passed in via --extern but not used in the crate. It so happens that there isn't a "correct" way to fix it right now aside from silencing the warning with use X as _;, but rustc is correct to warn in that case IMO.
What to do about this case practically is just sort of unfortunate, since rustc doesn't have enough information at any point to determine that this is just waiting on a missing cargo feature. The only clear options to me are to trigger this warning and require that users manually silence it (which is undoubtedly annoying) or not display the warning at all until the requisite feature is added to cargo (which seems similarly annoying).
A more complex but complete solution would be to have some way of telling rustc about all the targets you intend to compile in the future that should be considered in determining whether a crate is "used" without actually fully compiling each of those targets. Actually making this work well is a bit outside the reach of my imagination at the moment, and it seems of little value once we get cargo build-target-specific dependencies working.
Sounds like the best thing would be to push the effort to allow per-target depenencies in cargo forward. Sadly that's a process that's been slow going since 2015. There has been some recent effort from @pwoolcoc to write up an RFC recently though (helped by @alexreg), so maybe there's hope!
I think that having a lint for unnecessary dependencies in Cargo.toml is a very important and useful thing
Reacted by mark, Jon Gjengset, Alexander Regueiro, Rushmore Mushambi, nWacky, Gabriel de Perthuis, Franck R., Stepan Henek, Alexis Luengas, albel727 and 35 more
FYI, while I'd like to have it implemented in upstream tools as well, I have released an independent tool that does such an unused crates lint.
Reacted by Bernardo Ferrari, repi, Lu, Wangshan, Evan Stoll, Ingvar Stepanyan, Daniel Schaefer, Michael Dougherty, Jonas Platte, Joseph Azevedo, nielsle and 1 more
While this is still open is there a quick check that can be performed that will confirm whether a dependency is still necessary or not?
For example if I comment or remove a dep from Cargo.toml and run "cargo check --all-targets", will I always get an error if the dep is still needed, and conversely does the absence of any errors indicate that the dep is unused?
@deepink-mas The lint is in rustc mostly to support non-cargo build systems. For cargo there needs to be cargo level comparison between multiple units, which isn't implemented in cargo right now.
Activity
cramertj commentedon Jan 2, 2019
IMO it should be based on the
--externargs provided to rustc, and should not ignore "for-side-effects-only" imports now that we can douse some_crate as _;mark-i-m commentedon Jan 2, 2019
So as far as I can tell, the set of unused crates is computed here:
rust/src/librustc_typeck/check_unused.rs
Line 74 in ec19464
tcx. Is this the code that needs to be updated?Nemo157 commentedon Jan 3, 2019
This might have issues with adding dependencies-of-dependencies to force specific versions (I'm not sure how common that pattern is, and I guess they could be treated as "for-side-effects-only" imports as @cramertj mentions above).
dekellum commentedon Jan 3, 2019
In a project, I was just adding such (originally-)transitive dependencies to get a
-Z minimal-versionsbuild working. At least before "unused_extern_crates" is changed to default to "warn", perhaps anallow=unusedflag could be supported on the Cargo.toml dependency itself, like the#[allow(some_lint)]attribute in code?cramertj commentedon Jan 3, 2019
@dekellum Is there a reason you want to allow it in Cargo.toml rather than
use <cratename> as _;as I suggested above?dekellum commentedon Jan 3, 2019
I agree both that
use some_crate as _;should not trigger the unused_extern_crate lint (should not be treated as unused) and with the concern for the use-case raised by @Nemo157. Needing to adduse some_crate as _;for each of these originally-transitive dependencies is more cumbersome, when just wanting to guide cargo's dependency resolution, where nothing really needs to be imported as far as rustc is concerned. Note also in my case, using the[patch]section of Cargo.toml didn't work for the such resolution adjustment.jonhoo commentedon Jan 16, 2019
We'd also have to make sure that if you have, say, two binaries in a crate, and
Cargo.tomllists a dependency that is only used by one of them, compiling the other shouldn't generate a warning.cramertj commentedon Jan 16, 2019
@jonhoo IMO that's a bug in cargo that it doesn't allow specifying per-build-target dependencies (or maybe it does, in which case users should do that).
jonhoo commentedon Jan 16, 2019
@cramertj yeah, I agree, the real solution would be to have per-target dependencies, but sadly that's not something we have yet. There's some discussion in rust-lang/cargo#1982 on how we may add support for dependencies for binary targets, which would go a long way, but that has been open for a while. Until we get support for that though, we'd have to make sure that the lint doesn't erroneously give a warning in those cases.
cramertj commentedon Jan 16, 2019
@jonhoo It seems fine to me to silence those cases using
use X as _;. They are unused external crates, and it's wrong for them to be passed in via--externbut not used in the crate. It so happens that there isn't a "correct" way to fix it right now aside from silencing the warning withuse X as _;, butrustcis correct to warn in that case IMO.What to do about this case practically is just sort of unfortunate, since
rustcdoesn't have enough information at any point to determine that this is just waiting on a missing cargo feature. The only clear options to me are to trigger this warning and require that users manually silence it (which is undoubtedly annoying) or not display the warning at all until the requisite feature is added to cargo (which seems similarly annoying).A more complex but complete solution would be to have some way of telling
rustcabout all the targets you intend to compile in the future that should be considered in determining whether a crate is "used" without actually fully compiling each of those targets. Actually making this work well is a bit outside the reach of my imagination at the moment, and it seems of little value once we get cargo build-target-specific dependencies working.jonhoo commentedon Jan 16, 2019
Sounds like the best thing would be to push the effort to allow per-target depenencies in cargo forward. Sadly that's a process that's been slow going since 2015. There has been some recent effort from @pwoolcoc to write up an RFC recently though (helped by @alexreg), so maybe there's hope!
elichai commentedon May 14, 2019
I think that having a lint for unnecessary dependencies in
Cargo.tomlis a very important and useful thingest31 commentedon Aug 24, 2019
See also rust-lang/rust-clippy#4341
est31 commentedon Aug 30, 2019
FYI, while I'd like to have it implemented in upstream tools as well, I have released an independent tool that does such an unused crates lint.
31 remaining items
Implement warning for unused dependencies.
Auto merge of rust-lang#72603 - jsgf:extern-loc, r=nikomatsakis
Rollup merge of rust-lang#73945 - est31:unused_externs, r=Mark-Simula…
Rollup merge of rust-lang#73945 - est31:unused_externs, r=Mark-Simula…
Rollup merge of rust-lang#73945 - est31:unused_externs, r=Mark-Simula…
deepink-mas commentedon Feb 14, 2023
While this is still open is there a quick check that can be performed that will confirm whether a dependency is still necessary or not?
For example if I comment or remove a dep from Cargo.toml and run "cargo check --all-targets", will I always get an error if the dep is still needed, and conversely does the absence of any errors indicate that the dep is unused?
est31 commentedon Feb 14, 2023
@deepink-mas The lint is in rustc mostly to support non-cargo build systems. For cargo there needs to be cargo level comparison between multiple units, which isn't implemented in cargo right now.
Furthermore, there is no single cargo command that builds all units, see rust-lang/cargo#8437 (comment)
Remove the lint `unused_crate_dependencies` as it is giving false pos…
remove lint (broken in prepare-worker)
feat: Lint for unused crate dependencies
epage commentedon Apr 22, 2026
As part of https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#lintscargo, Cargo has a lint that wraps
unused_crate_dependencies, see https://doc.rust-lang.org/nightly/cargo/reference/lints.html#unused_dependencies.We currently punt on
dev-dependenciesuntil the doctest problem is resolved.