Renames are allowed to change the meaning of the program, due to shadowing.

[umanwizard]

For example:

fn f() {
    let x = 5;
    let y = x + 3;
    println!("{}", x + y);
}

if x is renamed to y, this becomes

fn f() {
    let y = 5;
    let y = y + 3;
    println!("{}", y + y);
}

which prints a different number. Rust-analyzer should probably refuse to rename x in this case.

[samlh]

Hm, if this was blocked I'd want a way to force it to happen anyway as sometimes I really do want semantic changes. Visual Studio's C# rename preview highlights name conflicts in red, but lets you do it anyway, which seems the best of both worlds.

[umanwizard]

Can you give an example of a situation where this behavior would be desirable?

[samlh]

Sure! It happens pretty often to me that one is a typo of the other, and renaming the two variables to be the same is the whole point.

[umanwizard]

That` is a good point; perhaps the best behavior would be to warn, or to offer different commands for "safe rename" vs. "force rename" (I'm not sure whether this is possible in the LSP protocol, though)

[Veykril]

The LSP spec(3.16.0+) supports user confirmation for specified renames with a description as to why confirmation is requested, that could be used in this case, that is if the rename creates name collisions we could add a confirmation via a ChangeAnnotation if supported.

[vigna]

Has this been solved? I just stumbled into the same problem in a less evident context: imagine something like

fn main() {
    let mut v = vec![0; 5];
    let node = 0;
    let mut iter = (0..5).into_iter();
    while let Some(curr) = iter.next() {
        v[curr] = node;
    }
    println!("{:?}", v);
}

but more complicated. If you rename the loop variable code to node the program semantics changes completely. I happened to do this together with a number of renamings and it took some time to find the broken one.

One vote for default behavior being to warn the user. Refactorings should not, by definition, change the program semantics.