Should non_snake_case lint ignore identifiers with leading _ ?

[pnkfelix]

We currently have a convention that unused variables that start with _ do not cause the unused variable lint to fire.

Should we put in a similar rule for the non_snake_case lint? (Perhaps just for variables with two leading underscores, __, ?)

---

In my particular case, I am using things like format!("foo {N}", N=name), and the expanded code causes the non-snake-case lint to fire, because it generates names like __argN ...

I could add an #[allow] annotation to the code in question, but this seems unfortunate to me. (Am I the only one who finds format strings easier to read if I use short capital letters for the named substitutions?)

[jonathanbuchanan]

I'd like to take this one. I was wondering, is there a test for this lint that I would have to update? I would look, but I'm on my phone now.

[nodakai]

Can we have a table of identifier lint rules? First of all, how is "snake_case" defined in Rust?

[Mark-Simulacrum]

format! has been fixed to no longer cause lint warnings. The general issue about ignoring __TestTestTest in the snake case lint is still a problem, though.

[oli-obk]

From the comments in #32683 this sounds like it needs an RFC. Should we just close this issue as it can be worked around with #[allow(non_snake_case)]?

[oli-obk]

Actually... this seems to have gotten fixed (https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=3116295265f7ab0fd5b435797d35e397). Likely because loads of lints have ben disabled in macro expansions.