"item TryFrom is imported redundantly" doesn't have automatic fix

[fintelia]

Recently rustc starting warning on imports of TryFrom that are redundant with the prelude.

use std::convert::TryFrom;

fn main() {
    let _ = u32::try_from(5i32);
}

produces:

warning: the item `TryFrom` is imported redundantly
   --> src/main.rs:1:5
    |
1   | use std::convert::TryFrom;
    |     ^^^^^^^^^^^^^^^^^^^^^
    |
   ::: /home/jonathan/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/prelude/mod.rs:129:13
    |
129 |     pub use core::prelude::rust_2021::*;
    |             ------------------------ the item `TryFrom` is already defined here
    |
    = note: `#[warn(unused_imports)]` on by default

Sadly, there's no automatic fix suggested here. For a single case it isn't too bad to do manually, but in a larger project the output may look more like:

$ cargo check --all-targets --all-features --message-format=short
    Checking image v0.24.8 (/home/jonathan/git/image)
src/io/mod.rs:3:5: warning: the item `TryFrom` is imported redundantly
src/codecs/avif/decoder.rs:6:5: warning: the item `TryFrom` is imported redundantly
src/codecs/bmp/decoder.rs:2:5: warning: the item `TryFrom` is imported redundantly
src/codecs/bmp/decoder.rs:4:25: warning: the item `Iterator` is imported redundantly
src/codecs/dxt.rs:10:5: warning: the item `TryFrom` is imported redundantly
src/codecs/farbfeld.rs:19:20: warning: the item `TryFrom` is imported redundantly
src/codecs/farbfeld.rs:19:29: warning: the item `TryInto` is imported redundantly
src/codecs/gif.rs:29:5: warning: the item `TryFrom` is imported redundantly
src/codecs/gif.rs:30:5: warning: the item `TryInto` is imported redundantly
src/codecs/hdr/decoder.rs:5:5: warning: the item `TryFrom` is imported redundantly
src/codecs/hdr/decoder.rs:7:5: warning: the item `Iterator` is imported redundantly
src/codecs/ico/decoder.rs:2:5: warning: the item `TryFrom` is imported redundantly
src/codecs/jpeg/decoder.rs:1:5: warning: the item `TryFrom` is imported redundantly
src/codecs/jpeg/encoder.rs:4:5: warning: the item `TryFrom` is imported redundantly
src/codecs/pnm/decoder.rs:1:5: warning: the item `TryFrom` is imported redundantly
src/codecs/pnm/decoder.rs:2:5: warning: the item `TryInto` is imported redundantly
src/codecs/tga/decoder.rs:11:5: warning: the item `TryFrom` is imported redundantly
src/codecs/tga/encoder.rs:6:11: warning: the item `TryFrom` is imported redundantly
src/codecs/tiff.rs:11:5: warning: the item `TryFrom` is imported redundantly
src/codecs/webp/encoder.rs:8:5: warning: the item `FromIterator` is imported redundantly
src/codecs/webp/decoder.rs:2:5: warning: the item `TryFrom` is imported redundantly
src/codecs/webp/extended.rs:1:5: warning: the item `TryInto` is imported redundantly
src/codecs/webp/huffman.rs:1:5: warning: the item `TryInto` is imported redundantly
src/codecs/webp/lossless.rs:7:5: warning: the item `TryFrom` is imported redundantly
src/codecs/webp/lossless.rs:8:5: warning: the item `TryInto` is imported redundantly
src/codecs/webp/lossless_transform.rs:1:5: warning: the item `TryFrom` is imported redundantly
src/codecs/webp/lossless_transform.rs:2:5: warning: the item `TryInto` is imported redundantly
src/codecs/webp/vp8.rs:16:5: warning: the item `TryInto` is imported redundantly
src/animation.rs:2:5: warning: the item `Iterator` is imported redundantly
src/image.rs:2:5: warning: the item `TryFrom` is imported redundantly
src/imageops/colorops.rs:548:28: warning: the item `ImageBuffer` is imported redundantly
src/codecs/hdr/decoder.rs:1024:9: warning: the item `Cursor` is imported redundantly
src/codecs/png.rs:792:9: warning: the item `ImageDecoder` is imported redundantly
src/codecs/png.rs:795:27: warning: the item `Read` is imported redundantly
warning: `image` (lib) generated 30 warnings
warning: `image` (lib test) generated 34 warnings (30 duplicates)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.67s

[heaths]

I'm wondering if this condition is even worth the lint. We recently hit this on a very large code base and fixing them all - especially without automatic fix-ups - is counterproductive to any benefit I can imagine. Most were from adding some types to our various crates' preludes and all the source that imported both wasn't cleaned up. Didn't need to until now.

I'd love to just #[allow(...)] these, but they are part of unused_import and I don't want to blanket allow those. If there's still time, can duplicate imports be their own lint? If there ambiguity that actually matters - i.e., duplicate symbol names are actually different types - that would result in a meaningful compiler error already. This seems like just "busy work".

[RossSmyth]

Yeah this breaks trying to test some software with #![deny(warnings)] with Miri. Probably something with build-std.

[kpreid]

I agree with the original report that it would be really valuable to have a fix for this — it turns a potentially large annoyance into a quick fix.

@RossSmyth deny(warnings) is in general fragile in that way; it means that your build can be broken by any compiler update.

[mmagician]

@chenyukang thanks for taking on the issue, very much a needed feature. Is this still being worked on?

[RossSmyth]

I agree with the original report that it would be really valuable to have a fix for this — it turns a potentially large annoyance into a quick fix.

@RossSmyth deny(warnings) is in general fragile in that way; it means that your build can be broken by any compiler update.

Yeah, I don't have it enabled but wrenching on some other crates they do.

[RossSmyth]

Another failure spotted in the wild:

Because of this line:
https://github.com/serialport/serialport-rs/blob/84f6066ffd92056829b91771afc7eebcbc6642e2/src/lib.rs#L35

And this time not even deny(warnings), but
https://github.com/serialport/serialport-rs/blob/84f6066ffd92056829b91771afc7eebcbc6642e2/src/lib.rs#L23
deny(unused)

Means that serialport-rs doesn't compile on nightly right now.

[chenyukang]

@chenyukang thanks for taking on the issue, very much a needed feature. Is this still being worked on?

sorry, there are some delays, I will continue to work on it.