Extract into function produces incorrect results when IndexMut is involved

[camelid]

rust-analyzer version: rust-analyzer version: 0.3.2519-standalone (6df1213 2025-06-29)

rustc version: rustc 1.87.0 (17067e9ac 2025-05-09)

editor or extension: VS Code (extension version 0.3.2519), also observed when using LSP server programmatically

relevant settings: N/A

code snippet to reproduce:

pub fn foo() {
    let mut arr = [0; 4];
    arr[0] = 0;
    println!("{arr:?}");
}

Highlight the arr[0] = 0; line, and select the extract into function code action. Observe that the extracted function takes arr by value rather than taking an &mut reference as it should. Not only is this incorrect as it doesn't capture the original code's meaning, but it doesn't compile either because the parameter is not marked as mut.

pub fn foo() {
    let mut arr = [0; 4];
    fun_name(arr);
    println!("{arr:?}");
}

fn fun_name(arr: [i32; 4]) {
    arr[0] = 0;
}

Changing arr to be a Vec instead causes a similar, but slightly different error. The extracted function takes &Vec instead of &mut Vec.

[camelid]

As I was looking into the source code to try to figure out a fix, I realized this is a more general problem (probably a known limitation) where any assignments that are more complicated than just x = ... are not extracted properly.

For example:

fn foo() {
    let mut v = 0;
    (_, v) = ("", 42);
}

fn foo() {
    let mut v = 0;
    fun_name(v);
}

fn fun_name(v: i32) {
    (_, v) = ("", 42);
}

I wonder if there's a way that the analysis could be rewritten to be type-directed, rather than syntax-directed, to avoid this limitation?

[ChayimFriedman2]

I wonder if there's a way that the analysis could be rewritten to be type-directed, rather than syntax-directed, to avoid this limitation?

Maybe. It's a bit hard. Perhaps we can use the planned speculative execution here, to put the code in a closure, then we can analyze its captures.