Dereferencing completions

[Veykril]

We currently have extra logic that duplicates completions with a (mutable) borrow if the expected type is a borrow but the completion's type is not. We should also have the inverse of that where we insert a deref * if the expected type is one dereference away from the completion's type and the expected type is Copy.

[boattime]

For this feature, should ref_match and a new field deref_match be separate properties in CompletionItem? Or should we refactor ref_match to include both references and dereferences in a single property?

[ChayimFriedman2]

I'd also be happy with completions that skip .await and iter() - RustRover does this.

[Veykril]

For this feature, should ref_match and a new field deref_match be separate properties in CompletionItem? Or should we refactor ref_match to include both references and dereferences in a single property?

we can repurpose ref_match, we won't have a situation where both adding a ref and a deref would apply at the same time

[Veykril]

I'd also be happy with completions that skip .await and iter() - RustRover does this.

skip? You mean it inserts those?

[ChayimFriedman2]

I'd also be happy with completions that skip .await and iter() - RustRover does this.

skip? You mean it inserts those?

I meant that we e.g. complete filter_map() on Vec, and turn it into iter().filter_map(). Similar thing for .await.

[Veykril]

Ah right, we have #15369 for the iterator ones

[lnicola]

I think we can now close this.