Removability of unused imports for traits seemingly conditional to markdown in docs
@zvavybir is already working on this.
Since Jun 17, 2026.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
I'm working on a crate that automatically generates Rust types for another crate. The generation of the imports for each file is in itself pretty generic, and we use cargo clippy --fix to automatically trim out the imports that rustc flags as unused.
In one of those files, unused imports are correctly flagged, but rustc's diagnostic does not provide a suggested replacement that's MachineApplicable for such imports targeting traits. However, if I manually change a #[doc] attribute elsewhere in the file to remove some markdown formatting, rustc starts seeing these imports as being able to be removed automatically.
I tried to produce a minimal code sample that reproduces this bug but was unsuccessful, so instead I've pushed that crate to this repository: https://github.com/babolivier/tmp-ms-graph-tb. The file exhibiting this behaviour is src/paths/me_messages_message_id_move.rs. Running cargo check shows unused imports are correctly identified, but does not offer to remove them with cargo fix (which, using the relevant options, can be correlated with the diagnostic Cargo gets from rustc). However, removing/commenting out the #[doc] attribute on line 52 (or even just removing the markdown link) seems to make rustc realise these imports can be removed automatically.
I've tried digging into why this could happen, including looking through rustc's code around the handling of unused imports, but came short (I'm not very familiar with this code base). Hopefully I've filed this bug in the right place/way, apologies if not.
Meta
rustc --version --verbose:
rustc 1.94.1 (e408947bf 2026-03-25)
binary: rustc
commit-hash: e408947bfd200af42db322daf0fadfe7e26d3bd1
commit-date: 2026-03-25
host: x86_64-unknown-linux-gnu
release: 1.94.1
LLVM version: 21.1.8
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.