Iterate over maybe_unused_trait_imports
when checking dead trait imports
#96873
Labels
E-easy
Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
E-help-wanted
Call for participation: Help is requested to fix this issue.
E-mentor
Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
The resolver gathers a list of possibly unused trait imports in
maybe_unused_trait_imports
. This list is passed to resolver outputs, into themaybe_unused_trait_import
query. This query takes aLocalDefId
and returns whether the import is possibly unused.This is used by the post-typeck unused import check in
rustc_typeck::check_unused
. This query iterates over all theuse
statements in the crate, checks whether they may be unused trait imports, and warns if they are indeed unused.As there are typically very few unused trait imports compared to the number of items in a crate, it would make sense to directly iterate on
maybe_unused_trait_imports
.Steps:
maybe_unused_trait_imports
anFxIndexSet
both inResolver
andResolverOutputs
, this will ensure a deterministic iteration order;maybe_unused_trait_import
query and give it the signaturemaybe_unused_trait_imports: () -> FxIndexSet<LocalDefId>
, and adapt the call site; we do not want to accesstcx.resolutions(())
directly, as this would prevent the query system from detecting that the set has not changed;rustc_typeck::check_unused::check_crate
, inlinecheck_import
and replace the loop overtcx.hir().items
by a loop overtcx.maybe_unused_trait_imports(())
;tcx.def_kind
there can be removed too (or replaced by a debug-assertion): the set may only point to use statements.Extra:
item.span.is_empty()
, and the consequences of removing that check;FxIndexSet
to a simpleVec
when producingResolverOutputs
fromResolver
.I am available on Zulip for any question.
The text was updated successfully, but these errors were encountered: