Remove "blacklist" terminology

[bossmc]

Picking up where #5896 left off, this renames the blacklisted_name lint to disallowed_names (pluralised for compliance with naming conventions). The old name is still available though is deprecated (both in the lint name, and in the TOML configuration file).

This has been proposed/requested a few times, most recently in #7582 where @xFrednet suggested pinging the Clippy team when a PR was created hence...

cc: @rust-lang/clippy

changelog: [disallowed_names] lint replaces blacklisted_name

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Manishearth (or someone else) soon.

Please see the contribution instructions for more information.

[xFrednet]

Hey @bossmc, welcome to Clippy, and thank you for the PR!

As suggested in the issue, a ping to @rust-lang/clippy as a general FYI and to see if anybody has any concerns. Also cc: @Jarcho

I'm still in favor of this change 🙃

[flip1995]

If other people don't want to read up on the other PR: From the Clippy team at that time, no one expressed their opposition to that change. But because from then to now, only Manish and I (and Matthias as a member-for-triage-rights 😄) are left, we can get more opinions.

I'm still fine with moving forward with this, as long as no compelling arguments should come up against it.

---

@bossmc Please add the old name to this test file to make sure that the deprecation message is printed for the old name:

rust-clippy/tests/ui-toml/conf_deprecated_key/clippy.toml

Line 2 in 4970527

cyclomatic-complexity-threshold = 42

[bossmc]

Done, good spot, thanks!

One observation I have - this change means that if someone uses the disallowed_names lint and the blacklisted-names configuration key they'll get the deprecation warning on the configuration, but their configuration will be ignored by the lint. OTOH if they use the disallowed-names configuration and the blacklisted_name lint they'll get the warning but the configuration will be processed. In fact, the old configuration will never be used which isn't quite what one might expect from "deprecated".

This MR's behaviour matches the equivalent behaviour from the cyclomatic-complexity -> cognitive-complexity rename so there's precedent, but I wanted to just flag this in case we wanted to do more here?

[flip1995]

Thanks for pointing that out! I think erroring on a deprecated conf value is wrong, because it breaks the configuration of people. I prepared a patch (that can be applied on b3c94c0, that only warns on deprecated conf names and additionally sets the value given to the deprecated name to the new conf name. I attached the patch file: conv.txt

For your commits: Can you please first rename files in a separate commit with git mv and then apply the renaming changes inside the files (or the other way around, but file renaming should be its own commit)? git doesn't seem to be able to figure out the renamings in this PR.

[bossmc]

I've had a look at your patch, and it looks reasonable, I feel though that it probably belongs in its own MR and we can make the one-line change in whichever one lands second rather than confusing this (already quite wide-ranging) MR.

On the commits - as I understand it git(hub) doesn't look at the individual commits when calculating diffs (especially the style of diff that GitHub uses for MRs) the detection of renames/moves is heuristic. This is even true for a single commit, git mv is simply a combination of git rm and git add (and the heuristics will confidently spot this rename since the file contents are identical). If you run git diff --find-renames=30 origin/master then (most of) the renames are caught (the only one that's missed is a one-line file that's "completely" changed and thus the heuristic misses it).

Additionally, the way these commits are arranged means that each commit builds and passes tests, doing the renames in separate commits will introduce failing commits to the tree, potentially causing issues is git bisect or in rebasing/porting this change (if needed) in future.

Given the above, I propose to leave the commits as is and apologise on behalf of GitHub for the slightly more annoying review job.

[flip1995]

as I understand it git(hub) doesn't look at the individual commits when calculating diffs (especially the style of diff that GitHub uses for MRs) the detection of renames/moves is heuristic.

Right, when you look at the diff of a range of commits (like github does), you need the --find-renames flag in order to get the renames. However, when looking at individual commits, detecting renames with otherwise completely unchanged files should work completely without flags, because the similarity index is 100% for all files.

Additionally, the way these commits are arranged means that each commit builds and passes tests, doing the renames in separate commits will introduce failing commits to the tree

We don't really care about that. We don't require every commit to build-pass or even test-pass, because we can be sure that the bors commits are always test-pass. So there are already many commits in the tree that aren't build-pass or test-pass.

I've had a look at your patch, and it looks reasonable, I feel though that it probably belongs in its own MR and we can make the one-line change in whichever one lands second rather than confusing this (already quite wide-ranging) MR.

Makes sense. But we should do that, before merging this.

[bors]

☔ The latest upstream changes (presumably #8999) made this pull request unmergeable. Please resolve the merge conflicts.

[bossmc]

I've rebased this to master and augmented it with the function added in #9252 so the deprecated config key is still respected (as well as emitting a warning about the new name).

[Manishearth]

@bors r+

thanks!

[bors]

📌 Commit 56c9cc4 has been approved by Manishearth

It is now in the queue for this repository.

[bors]

⌛ Testing commit 56c9cc4 with merge a0ed687...

[bors]

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