IDE: add imports after pasting code

[Kobzol]

This PR adds a copy/paste postprocessor that tries to import unresolved items from the pasted code. There is also some crude support for selecting between ambiguous imports.

I took inspiration from the Kotlin plugin, mainly with the data flavor thing, I'm not sure how that's supposed to work.

Fixes: #7241

changelog: Automatically import unresolved items after copy/pasting Rust code.

[mchernyavsky]

The copy-paste processor adds wrong import in this case:

• Before

mod a {
    pub struct S;
    pub fn foo1() -> S { S }
}

mod b {
    struct S;
    fn foo2() -> S { S } // copied
}

/*caret*/

• After

use crate::a::S;

mod a {
    pub struct S;
    pub fn foo1() -> S { S }
}

mod b {
    struct S;
    fn foo2() -> S { S }
}

fn foo2() -> S { S }

[Kobzol]

Right. In this case, b::S cannot be imported, because it's private. In the current implementation, if there is only a single import candidate, it is always imported on a best-effort basis, the import map is only consulted if there are multiple candidates.

Should I change it so that if the original item cannot be imported, the auto import won't do anything? Or should we display some kind of conflict dialog like in the move refactoring?

[mchernyavsky]

@Kobzol Kotlin plugin adds imports for items even if they are private. We can add use's with fully-qualified names to help users to understand what items are missed.

@Undin What do you think?

[dima74]

In the current implementation, if there is only a single import candidate, it is always imported on a best-effort basis, the import map is only consulted if there are multiple candidates.

I think import map should be used even if there is a single candidate, to ensure that we add import for the correct item

[Kobzol]

@dima74 How should this work after #8266 is implemented? Should it use a separate implementation (this PR) or somehow build on top of #8266 and add support for ambiguous imports?

[dima74]

@Kobzol I thinks these are two independent features, and you should keep current implementation (taking into account #7597 (comment))

[Kobzol]

I fixed some things and added support for pat bindings.

[dima74]

I am not sure about this check. If we do the check, then import will not be added, and we may end up with binding recognized as variable name (user will see the warning about other match arms unreachable). If we don't do the check, import will be added and we end up with duplicated names in scope (user will see the corresponding error). I don't know which error is easier to fix (user need to change code after paste anyway). What do you think?

[Kobzol]

I think that we should not do the check after all. Duplicated names are a more explicit error that makes it easy to see where the problem is, the other error is a bit more subtle.

[Kobzol]

Currently, if the thing that we would normally import is private, it will not be imported. What about this: if we encounter an element at some relative position which should be resolved to a fully qualified item, but the item is not offered by the auto import fix (since it is probably private), we would instead fully qualify that path. Then instead of an unresolved path (or a path resolved to some unrelated local item), the user would be left with a fully qualified path and a red underline with a quick action to make that item public.

A similar approach with fully qualifying the name could also be used if the name to be imported is already present in the target scope. But this can be left for another PR.

[dima74]

Currently, if the thing that we would normally import is private, it will not be imported. What about this: if we encounter an element at some relative position which should be resolved to a fully qualified item, but the item is not offered by the auto import fix (since it is probably private), we would instead fully qualify that path. Then instead of an unresolved path (or a path resolved to some unrelated local item), the user would be left with a fully qualified path and a red underline with a quick action to make that item public.

I like this idea, but lets do it in another PR for easier review process

[Kobzol]

@dima74 I rebased on master, squashed the commits and integrated code from #9153.

[dima74]

bors r+

[bors]

Build succeeded:

• check