False warning with #[warn(unused_imports)] for std::ops::Deref

[raphaelcohn]

The lint #[warn(unused_imports)] produces a false warning of "warning: unused import: ::std::ops::Deref", which is incorrect; following the warning and removing the import creates code that does not compile.

In my lib.rs I have use ::std::ops::Deref.

In submodules, which use use super::* imports, I have some code that explicitly calls xxx.deref(). Following the warning and removing the import from lib.rs causes code to break. (As an aside, this code explicitly calls deref() because trying to auto-deref confuses the compiler in this code).

[ishitatsuyuki]

Please show a full example of the code that breaks. Also, if auto deref is an issue for you, please use UFCS.

[ExpHP]

Sounds like #45268 . The triggering condition is the combination of (1) a use of a trait, (2) a glob use which imports the first use, and (3) code in the same module as the second use that only uses the trait through method resolution (without naming the trait), all of which you conveniently mentioned. 🙂

[raphaelcohn]

@ExpHP - Yep, it sounds very similar, and one would hope a fix to that would fix this. I also use a lot of tiny submodules for similar reasons - and lots of include!() so I can have one struct, const or function per file - makes it far, far easier to work on large code bases with many devs...

[raphaelcohn]

@ExpHP Anyone on the compiler team made any progress on this? As a fault, similar things are cropping up quite often in my code... It's becoming a code quality issue for me.

[ExpHP]

Heh; I'm also just a user! I know how you feel about it, because it continues to crop up increasingly often in my code as well. That said, I am subscribed to updates in all of the duplicates I could find, and haven't heard much activity. (though two organization members were recently hit by it)

Presumably anything not related to the 2018 edition is lower priority right now, given its impending release. This doesn't mean that no progress can be made on this, but I suspect it might take a PR from a non-team member to push things forward.

I tried looking into it a long time ago, but the best I could manage to come up with was this amateur analysis here with no idea how to fix it. :/

[raphaelcohn]

@ExpHP - Sorry - my abbreviated first sentence implied the wrong thing! (:-( I'm very grateful for your efforts, and it helped me understand things better. As a heavy Rust user, I find there's a number of recurring problems with overall quality with anything that's not used by the 'core' org, and it seems to be difficult to get their attention. I'm too focused on trying to get my projects finished for clients to be delving into things, but I really appreciate your efforts. I wish Rust 2018 was ditched, and focus was placed on polish and finishing ideas (eg TryFrom being a case in point). Making sure associated constants work properly without sometimes crashing the compiler, properly improving the disaster that is the module system that simply doesn't scale for multi-user projects using frequent check ins (aka good practice) rather than tinkering [essentially, being able to break up a module into a file per item w/o resorting to includes or weird pub use syntax], making the borrow checker more intelligent so I don't spend 4 hours a week working around non-faults (eg provably safe mutable borrows of separate fields of a struct, being able to refactor common access patterns into a method without then breaking the borrow checker), making the compiler respect the declaration order of constants, getting rid of the silly cruft that occurs when an associated constant in a generic struct is used (it seems it thinks an associated type is missing), the list could go on...

Rust could really use a benevolent dictator...

[ExpHP]

Uhh, wow! Certainly sounds like you needed to vent!

A number of the things you point out are things that are being actively worked on, and are an awful lot more complicated than they may seem on the surface.

The deal with associated consts---which I assume is the fact that they don't work as the N in [T; N] in generic code---is well known and it bothers the heck out of everybody; but it's not simply that this one little case wasn't accounted for; rather, I imagine the case is that all of the other places where consts work in [T; N] are a pure hack! Integers are not part of the type system in rust. Type inference, unification and trait solving know nothing about them. Making this one last thing work in a scalable manner would seem to require basically half of the entire infrastructure of const generics... which is a planned feature that recently got a big PR.

(yeah, I know, the current error message sucks. I chalk it up to whatever hack there must be to make everything else work)

Other things like TryFrom are blocked on yet other things (never_type) in order to make sure they don't come out unpolished.

[raphaelcohn]

@ExpHP ta for the detailed reply. Signing off for now, least I side track this issue with irrelevancy...

[sanxiyn]

I am so sorry that this is causing trouble for you. On the other hand, @ExpHP's analysis is correct. Closing as a duplicate.

[raphaelcohn]

@sanxiyn Good practice would be to put a reference to the duplicate bug in your close message...

[sanxiyn]

Right. This is a duplicate of #45268. Thanks for reminding.

[raphaelcohn]

Ta