Open balthild opened 2 weeks ago
Yes, we should filter out auto-importing completions if they shadow something that's in scope (that satisfies the "well-known" concept you are speaking of, since Ok
is in the prelude, and as such already in scope).
There are some crate providing items with same names as well-known items from
std
. If the item from the crate is not an alias of the one fromstd
, importing it causes errors. Most of the time, the errors are confusing, as it is really unusual, unless the crates' user has encountered it before.For example,
anyhow::Ok
conflicts withstd::result::Result::Ok
, and unlike thestd
one as an enum variant, it is a function. If I typeok
in the editor and adopt the first candidate without checking the completion list carefully,anyhow::Ok
will be imported, breaking otherOk
s (e.g. theOk
in match patterns).In my opinion, most of the time when using auto-import, well-known items like
std::result::Result::Ok
should be always picked unless the other ones are specified purposely or already imported. It is not ergonomic to require developers to check such items carefully every times they use auto-import.However, identifying which item is "well-known" seems to exceed the capabilities
rust-analyzer
should have. It is also not always possible to persuade the crates' maintainer to remove such footguns. As an alternative,rust-analyzer
could be able to be configured to block specified items being auto-imported.Related: https://github.com/dtolnay/anyhow/issues/201