Repository navigation
unused_dependencies can't be granularly disabled/expected #17510
Description
Problem
So, the specific use case I'm running into here is allocator-api2 for the hashbrown crate, which is enabled by default for MSRV reasons: even though allocator_api was just stabilised on nightly, we still need it for most users.
However, with the nightly feature, we explicitly do not use this dependency at all, and thus it gets reported as unused. The only way to fix this would be to use --no-default-features alongside the nightly feature, plus every feature except allocator-api2, to avoid the unused dependency.
It would be nice if, in this case, we could simply mark this one case as being acceptable as an unused dependency, rather than completely disabling the lint. Or even expect(...) the lint somehow and acknowledge it.
Steps
No response
Possible Solution(s)
Since the resolver is additive, we should not have some way to disable certain feature combinations, but we could have a way to accept unused dependencies when certain features are enabled. For example, in this case, specifically configure the lint to state that, whenever the nightly feature is enabled, allocator-api2 will be unused. In this case, cargo should be able to determine that, since allocator-api2 is an optional dependency, it will only be unused if it's explicitly enabled.
Notes
No response
Version
cargo 1.100.0-nightly (98a09e7e7 2026-09-21)
release: 1.100.0-nightly
commit-hash: 98a09e7e7d62850f14e5b6132101fc1edd19a16f
commit-date: 2026-09-21
host: x86_64-unknown-linux-gnu
libgit2: 1.9.6 (sys:0.21.0 vendored)
libcurl: 8.21.0-DEV (sys:0.4.90+curl-8.21.0 vendored ssl:OpenSSL/3.6.3)
ssl: OpenSSL 3.6.3 9 Jun 2026
os: Arch Linux Rolling Release [64-bit]
Activity
epage commentedon Sep 24, 2026
rust-lang/rfcs#3920 explored ways to handle this. At the time, we deferred work on it because few use case seemed impacted that it wasn't worth blocking the lint on it.
clarfonthey commentedon Sep 24, 2026
Yeah, that makes a lot of sense. I mostly just wanted to file an issue for it to track it, since it appears that there weren't any issues in the repo for it.
rktaxe commentedon Sep 30, 2026
Would adding
use ::allocator_api2 as _;to the rust code do the trick? That hack seems to work for me in similar circumstances.joshtriplett commentedon Sep 30, 2026
It seems like this isn't a false positive so much as an unused dependency that would be annoying to remove.
Rather than figuring out how to disable the line, could we figure out how to simplify disabling the dependency?
clarfonthey commentedon Sep 30, 2026
That might be hard to do, honestly, since it would break the composability of features. The idea of disabling some dependencies if some features are enabled feels like it would be difficult to reason about.
joshtriplett commentedon Sep 30, 2026
@clarfonthey I wasn't suggesting we could fix it in the crate. I'm suggesting that we could make it easier to handle "not this default feature" in rust's dependency on it.
Fix Rust 1.100 lints (#8592)