diff options
| author | Kevin Reid <kpreid@switchb.org> | 2024-05-22 22:21:01 -0700 |
|---|---|---|
| committer | Kevin Reid <kpreid@switchb.org> | 2024-05-23 15:51:33 -0700 |
| commit | 0f5338cd903c715d411dee6af95f076177914e42 (patch) | |
| tree | 107a0012ff6624722bbac26b0d601babd8f04b0a /clippy_lints/src/missing_assert_message.rs | |
| parent | 76856ffb576fb2dff472481a6389d42ca836db6f (diff) | |
For restriction lints, replace “Why is this bad?” with “Why restrict this?”
The `restriction` group contains many lints which are not about necessarily “bad” things, but style choices — perhaps even style choices which contradict conventional Rust style — or are otherwise very situational. This results in silly wording like “Why is this bad? It isn't, but ...”, which I’ve seen confuse a newcomer at least once. To improve this situation, this commit replaces the “Why is this bad?” section heading with “Why restrict this?”, for most, but not all, restriction lints. I left alone the ones whose placement in the restriction group is more incidental. In order to make this make sense, I had to remove the “It isn't, but” texts from the contents of the sections. Sometimes further changes were needed, or there were obvious fixes to make, and I went ahead and made those changes without attempting to split them into another commit, even though many of them are not strictly necessary for the “Why restrict this?” project.
Diffstat (limited to 'clippy_lints/src/missing_assert_message.rs')
| -rw-r--r-- | clippy_lints/src/missing_assert_message.rs | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/clippy_lints/src/missing_assert_message.rs b/clippy_lints/src/missing_assert_message.rs index 04df7b7a7e5..dd98352da86 100644 --- a/clippy_lints/src/missing_assert_message.rs +++ b/clippy_lints/src/missing_assert_message.rs @@ -10,7 +10,7 @@ declare_clippy_lint! { /// ### What it does /// Checks assertions without a custom panic message. /// - /// ### Why is this bad? + /// ### Why restrict this? /// Without a good custom message, it'd be hard to understand what went wrong when the assertion fails. /// A good custom message should be more about why the failure of the assertion is problematic /// and not what is failed because the assertion already conveys that. |
