Auto merge of #12885 - lochetti:clippy_proper_noun, r=flip1995

Using Clippy as a proper noun when refering to the unique entity Clippy

I was reading some documentation (specially the book) and I notice some few usages of the word `clippy` when refering to the Project/Tool. As we already have in the majority of the documentation, in those cases, Clippy is a proper noun, and because of that should be used capitalized.

This is, for sure, not an exhaustive change: quite the opposity, it was just some cases that I could verify with not so much effort.

changelog: Docs: capitalizing the `clippy` word in some usages.

README.md

@@ -172,7 +172,7 @@ You can add options to your code to `allow`/`warn`/`deny` Clippy lints:
 
 Note: `allow` means to suppress the lint for your code. With `warn` the lint
 will only emit a warning, while with `deny` the lint will emit an error, when
-triggering for your code. An error causes clippy to exit with an error code, so
+triggering for your code. An error causes Clippy to exit with an error code, so
 is useful in scripts like CI/CD.
 
 If you do not want to include your lint levels in your code, you can globally
@@ -238,7 +238,7 @@ define the `CLIPPY_DISABLE_DOCS_LINKS` environment variable.
 ### Specifying the minimum supported Rust version
 
 Projects that intend to support old versions of Rust can disable lints pertaining to newer features by
-specifying the minimum supported Rust version (MSRV) in the clippy configuration file.
+specifying the minimum supported Rust version (MSRV) in the Clippy configuration file.
 
 ```toml
 msrv = "1.30.0"

book/src/configuration.md

@@ -99,7 +99,7 @@ For more details and options, refer to the Cargo documentation.
 ### Specifying the minimum supported Rust version
 
 Projects that intend to support old versions of Rust can disable lints pertaining to newer features by specifying the
-minimum supported Rust version (MSRV) in the clippy configuration file.
+minimum supported Rust version (MSRV) in the Clippy configuration file.
 
 ```toml
 msrv = "1.30.0"

book/src/development/basics.md

@@ -107,7 +107,7 @@ More about [intellij] command usage and reasons.
 
 ## lintcheck
 
-`cargo lintcheck` will build and run clippy on a fixed set of crates and
+`cargo lintcheck` will build and run Clippy on a fixed set of crates and
 generate a log of the results.  You can `git diff` the updated log against its
 previous version and see what impact your lint made on a small set of crates.
 If you add a new lint, please audit the resulting warnings and make sure there

book/src/development/defining_lints.md

@@ -163,11 +163,11 @@ declare_clippy_lint! {
     ///
     /// ### Example
     /// ```rust
-    /// // example code where clippy issues a warning
+    /// // example code where Clippy issues a warning
     /// ```
     /// Use instead:
     /// ```rust
-    /// // example code which does not raise clippy warning
+    /// // example code which does not raise Clippy warning
     /// ```
     #[clippy::version = "1.70.0"] // <- In which version was this implemented, keep it up to date!
     pub LINT_NAME, // <- The lint name IN_ALL_CAPS

book/src/development/proposals/syntax-tree-patterns.md

@@ -428,7 +428,7 @@ selection of possible matches is produced by the pattern syntax. In the second
 stage, the named subpattern references can be used to do additional tests like
 asserting that a node hasn't been created as part of a macro expansion.
 
-## Implementing clippy lints using patterns
+## Implementing Clippy lints using patterns
 
 As a "real-world" example, I re-implemented the `collapsible_if` lint using
 patterns. The code can be found
@@ -572,7 +572,7 @@ The pattern syntax and the *PatternTree* are independent of specific syntax tree
 implementations (rust ast / hir, syn, ...). When looking at the different
 pattern examples in the previous sections, it can be seen that the patterns
 don't contain any information specific to a certain syntax tree implementation.
-In contrast, clippy lints currently match against ast / hir syntax tree nodes
+In contrast, Clippy lints currently match against ast / hir syntax tree nodes
 and therefore directly depend on their implementation.
 
 The connection between the *PatternTree* and specific syntax tree
@@ -690,7 +690,7 @@ change, only the `IsMatch` trait implementations need to be adapted and existing
 lints can remain unchanged. This also means that if the `IsMatch` trait
 implementations were integrated into the compiler, updating the `IsMatch`
 implementations would be required for the compiler to compile successfully. This
-could reduce the number of times clippy breaks because of changes in the
+could reduce the number of times Clippy breaks because of changes in the
 compiler. Another advantage of the pattern's independence is that converting an
 `EarlyLintPass` lint into a `LatePassLint` wouldn't require rewriting the whole
 pattern matching code. In fact, the pattern might work just fine without any
@@ -777,7 +777,7 @@ complexity to solve a relatively minor problem.
 
 The issue of users not knowing about the *PatternTree* structure could be solved
 by a tool that, given a rust program, generates a pattern that matches only this
-program (similar to the clippy author lint).
+program (similar to the Clippy author lint).
 
 For some simple cases (like the first example above), it might be possible to
 successfully mix Rust and pattern syntax. This space could be further explored
@@ -789,7 +789,7 @@ The pattern syntax is heavily inspired by regular expressions (repetitions,
 alternatives, sequences, ...).
 
 From what I've seen until now, other linters also implement lints that directly
-work on syntax tree data structures, just like clippy does currently. I would
+work on syntax tree data structures, just like Clippy does currently. I would
 therefore consider the pattern syntax to be *new*, but please correct me if I'm
 wrong.
 
@@ -982,5 +982,5 @@ pattern!{
 }
 ```
 
-In the future, clippy could use this system to also provide lints for custom
+In the future, Clippy could use this system to also provide lints for custom
 syntaxes like those found in macros.

clippy_dummy/PUBLISH.md

@@ -1,5 +1,5 @@
 This is a dummy crate to publish to crates.io. It primarily exists to ensure
-that folks trying to install clippy from crates.io get redirected to the
+that folks trying to install Clippy from crates.io get redirected to the
 `rustup` technique.
 
 Before publishing, be sure to rename `clippy_dummy` to `clippy` in `Cargo.toml`,

clippy_dummy/crates-readme.md

@@ -1,9 +1,9 @@
-Installing clippy via crates.io is deprecated. Please use the following:
+Installing Clippy via crates.io is deprecated. Please use the following:
 
 ```terminal
 rustup component add clippy
 ```
 
-on a Rust version 1.29 or later. You may need to run `rustup self update` if it complains about a missing clippy binary.
+on a Rust version 1.29 or later. You may need to run `rustup self update` if it complains about a missing Clippy binary.
 
 See [the homepage](https://github.com/rust-lang/rust-clippy/#clippy) for more information

lintcheck/README.md

@@ -1,6 +1,6 @@
 ## `cargo lintcheck`
 
-Runs clippy on a fixed set of crates read from
+Runs Clippy on a fixed set of crates read from
 `lintcheck/lintcheck_crates.toml` and saves logs of the lint warnings into the
 repo.  We can then check the diff and spot new or disappearing warnings.
 
@@ -84,7 +84,7 @@ This lets us spot bad suggestions or false positives automatically in some cases
 
 > Note: Fix mode implies `--all-targets`, so it can fix as much code as it can.
 
-Please note that the target dir should be cleaned afterwards since clippy will modify
+Please note that the target dir should be cleaned afterwards since Clippy will modify
 the downloaded sources which can lead to unexpected results when running lintcheck again afterwards.
 
 ### Recursive mode