Consider specific warning for trying to use an existing variable in a pattern

[jorendorff]

According to the book, this is a common mistake (common enough to call out specifically, anyway):

fn compare(x: i32, y: i32) {
    match x {
        y => println!("match"),   // wrong
        _ => println!("no match")
    }
}

fn main() { compare(3, 4); }

Rust currently emits 3 warnings:

• y argument is unused
• y match-binding is unused
• _ pattern is unreachable

All are correct. But if this really is a common pitfall, it'd better for Rust to have a specific diagnostic for this problem.

The last two warnings, in combination with the other binding y already in scope, strongly suggest that the programmer has made this exact mental mistake. The third warning in particular shows that the programmer expected the pattern y to be refutable.

The new warning could be something like: "the identifier y in this pattern introduces a new variable (it does not refer to the variable y declared here)"

(Of course shadowing an existing binding is normal in other circumstances; I'm only proposing a different warning for certain situations where Rust already emits warnings.)

[jorendorff]

The reason I bring this up is that I'm writing about this "possible pitfall" in Programming Rust, spending about half a page on it. To me that expenditure is regrettable. If Rust had a really great diagnostic for this, I wouldn't mention it at all.

[steveklabnik]

New warnings usually require an RFC; I'm not sure if this could be an existing warning modified slightly.

[nikomatsakis]

Related: I often get confused (momentarily...) by warnings about _ being unreachable because I've failed to import the name of some variant, but this seems to some extent to be because rustc still doesn't use Enum::Variant much of the time (but instead imports Variant directly into scope).

[nikomatsakis]

@jorendorff do you really think it's common that people use an existing variable name What do you think they are trying to do?

[jorendorff]

@nikomatsakis I don't think it's super common. I probably wouldn't have thought of it if TRPL didn't mention it. @steveklabnik Do you know where that passage came from? Is this really a common thing?

Anyway, what I imagine they're trying to do is match the exact value that's in the variable. Note that that's exactly what happens if you use the name of a constant in a pattern.

Elixir patterns have a "pin operator" that does this, so apparently it's something people want to do... sometimes?

[BGR360]

The book no longer contains any mention of this pitfall (as far as I can tell), but I could certainly understand people still stumbling over this. (for posterity, here's the section of the old book that talked about the pitfall)

New warnings usually require an RFC

Is this still true?