cc @JoshMcguigan

Thanks for the report!

I suspect a direct cause of this is that the expected_type field on CompletionContext doesn't consider the existence of a leading reference.

https://github.com/rust-analyzer/rust-analyzer/blob/e6a1c9ca60c19bf3b02b302e21d9f9fd9bd8a466/crates/ide_completion/src/context.rs#L310-L401

But an alternate solution, which might be better long term (?) is considering the leading reference as part of the thing being completed. In that case expected_type would stay as-is and we'd in this case just overwrite the existing &mut. The upside to this approach is if the user starts typing &con we could complete &mut context. The downside is if our ref completions were not very good, we could complete &mut con to perhaps context (deleting the &mut that the user has already entered).

In any event I'm glad to have this report as it gives an important additional use case to think about as I'm working on #8058.

I keep hitting this problem when trying to complete struct fields (where the name I am looking for might be one I don't entirely remember), and it'd be really nice to have it fixed. As encouragement, here's a self-contained example:

fn foo(_: &mut i32) {}
struct S {
    some_field_with_a_long_name: i32,
}

fn main() {
    let s = S {
        some_field_with_a_long_name: 100,
    };
    foo(&mut s.so/* cursor here */);           
}

Put the cursor at the specified point and hit tab (in VS Code), and the extra &mut is inserted:

    foo(&mut &mut s.some_field_with_a_long_name);