Change:
<ins> #![deny(non_snake_case)] #![allow(unused_variables)] #![allow(dead_code)] enum Foo { Bad { lowerCamelCaseName: bool, //~^ ERROR structure field `lowerCamelCaseName` should have a snake case name }, Good { snake_case_name: bool, }, } fn main() { let b = Foo::Bad { lowerCamelCaseName: true }; match b { Foo::Bad { lowerCamelCaseName } => {} Foo::Good { snake_case_name: lowerCamelCaseBinding } => { } //~^ ERROR variable `lowerCamelCaseBinding` should have a snake case name } if let Foo::Good { snake_case_name: anotherLowerCamelCaseBinding } = b { } //~^ ERROR variable `anotherLowerCamelCaseBinding` should have a snake case name if let Foo::Bad { lowerCamelCaseName: yetAnotherLowerCamelCaseBinding } = b { } //~^ ERROR variable `yetAnotherLowerCamelCaseBinding` should have a snake case name } </ins>

Discussion:
For example: This gives you a warning that should be snake case in the match arm. But at that point you don't really have much choice about it. Variable name warnings should be where the variable is named, and it isn't really named there. (Maybe there's some syntax like but who is going to bother with that?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please provide a working example without next time. It makes it easier to see what's going on here. Let's assume this one: You could instead write and have full control over the names of the binding and that's why the compiler is complaining. You are right in the way, that we should lint the original issue. I'm not sure how the the suggestion goes in terms of machine applicability and renaming of further instances of this variable. Let's see what the future will bring :)
Direct repro link: Current warning: Seems like a diagnostics fix to change the help to
We discussed this in the lang team meeting, and we agree with the proposal here. We shouldn't warn twice over the same field name; we should only warn about the definition, and not again when you match it. Note, in particular, that it seems like a relatively common pattern to disable these lints only in a module written by bindgen or otherwise written to match some external spec/API, but leave them enabled in the rest of your code. So, :+1: to not linting for field puns on field names that don't match the recommended style. (We should still lint when not punning, if you define a new local name that doesn't match the recommended style.)
Hi, I'd like to take this one. Just to make sure I'm understanding this right: We want to warn on identifier used to define the field name in the struct itself, and not on the match binding. Is that correct?
We definitely want to warn on the struct definition. My understanding is that we don't want to warn on the binding when you didn't actually write the binding ("for field puns"). So we don't warn on but would warn on (and definitely on ).
That makes a lot of sense.

Thanks! claim
Right, exactly. I would suggest starting by writing some (failing) test cases for the desired behavior including warning output. I would be happy to review that step and confirm.
I've put up a PR with the failing test case. How's this look? Are there any other cases I should test?