about summary refs log tree commit diff
path: root/clippy_lints/src/missing_assert_message.rs
diff options
context:
space:
mode:
authorKevin Reid <kpreid@switchb.org>2024-05-22 22:21:01 -0700
committerKevin Reid <kpreid@switchb.org>2024-05-23 15:51:33 -0700
commit0f5338cd903c715d411dee6af95f076177914e42 (patch)
tree107a0012ff6624722bbac26b0d601babd8f04b0a /clippy_lints/src/missing_assert_message.rs
parent76856ffb576fb2dff472481a6389d42ca836db6f (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.rs2
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.