Register redundant_field_names and non_expressive_names as early passes

[ebroto]

Similar names was moved to a pre-expansion pass to solve #2927, so I'm avoiding linting on code from expansion, which makes the dogfood (mostly, see below) pass.

I had to change new_without_default though, and although I understand why it was not triggering before, TBH I don't see why the binding inside the nested if_chain is being linted now. Any ideas? (it seems legit though as the code can be changed by the user)

changelog: Register redundant_field_names and non_expressive_names as early passes

Fixes #5356
Fixes #5521

[rust-highfive]

r? @matthiaskrgr

(rust_highfive has picked a reviewer for you, use r? to override)

[flip1995]

Thanks for finishing this!

The lint triggering in the if_chain is because the variables don't come from an expansion, but are written by the user. It's like they are macro arguments in e.g. assert_eq!(arg1, arg2).

@bors r+

[bors]

📌 Commit 4161823 has been approved by flip1995

[bors]

⌛ Testing commit 4161823 with merge fca76de...

[bors]

☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test
Approved by: flip1995
Pushing fca76de to master...

[sfackler]

@Mark-Simulacrum if the 1.44.1 window is still open, it might be worth backporting this to fix a stable-stable regression.

[Mark-Simulacrum]

@rust-lang/clippy we do have time to rebuild artifacts, but I don't know enough here to be able to say whether it's worth it or not. If we feel it is, could someone prepare a 1.44.1 branch on the clippy repository that we can checkout on rust-lang/rust's stable branch? (subtree has not yet hit rust-lang/rust stable).

[flip1995]

Today was another issue opened about this, so I would say, that it would be worth it, if possible. I try to push a working commit to a rust-1.44.1 branch.