Block specific items from being auto-imported

[balthild]

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 from std, 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 with std::result::Result::Ok, and unlike the std one as an enum variant, it is a function. If I type ok in the editor and adopt the first candidate without checking the completion list carefully, anyhow::Ok will be imported, breaking other Oks (e.g. the Ok 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: dtolnay/anyhow#201

[Veykril]

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).