Tweak some words improved representation

This PR has implemented improved representation.

- Use "lib" instead of "lifb"
- Use "triggered" instead of "triggere"
- Use "blacklisted_name" instead of "blackisted_name"
- Use "stabilization" instead of "stabilisation"
- Use "behavior" instead of "behaviour"
- Use "target" instead of "tartet"
- Use "checked_add" instead of "chcked_add"
- Use "anti-pattern" instead of "antipattern"
- Use "suggestion" instead of "suggesttion"
- Use "example" instead of "exampel"
- Use "Cheat Sheet" instead of "Cheatsheet"

Author: ydah

clippy_dev/src/main.rs

@@ -124,7 +124,7 @@ fn get_clap_config<'a>() -> ArgMatches<'a> {
                  * the lint count in README.md is correct\n \
                  * the changelog contains markdown link references at the bottom\n \
                  * all lint groups include the correct lints\n \
-                 * lint modules in `clippy_lints/*` are visible in `src/lifb.rs` via `pub mod`\n \
+                 * lint modules in `clippy_lints/*` are visible in `src/lib.rs` via `pub mod`\n \
                  * all lints are registered in the lint store",
                 )
                 .arg(Arg::with_name("print-only").long("print-only").help(

clippy_dev/src/new_lint.rs

@@ -133,7 +133,7 @@ fn to_camel_case(name: &str) -> String {
         .collect()
 }
 
-fn get_stabilisation_version() -> String {
+fn get_stabilization_version() -> String {
     fn parse_manifest(contents: &str) -> Option<String> {
         let version = contents
             .lines()
@@ -199,7 +199,7 @@ fn get_lint_file_contents(lint: &LintData<'_>, enable_msrv: bool) -> String {
         },
     };
 
-    let version = get_stabilisation_version();
+    let version = get_stabilization_version();
     let lint_name = lint.name;
     let category = lint.category;
     let name_camel = to_camel_case(lint.name);

clippy_lints/src/assign_ops.rs

@@ -50,7 +50,7 @@ declare_clippy_lint! {
     /// ### Known problems
     /// Clippy cannot know for sure if `a op= a op b` should have
     /// been `a = a op a op b` or `a = a op b`/`a op= b`. Therefore, it suggests both.
-    /// If `a op= a op b` is really the correct behaviour it should be
+    /// If `a op= a op b` is really the correct behavior it should be
     /// written as `a = a op a op b` as it's less confusing.
     ///
     /// ### Example

clippy_lints/src/casts/cast_slice_different_sizes.rs

@@ -121,7 +121,7 @@ fn expr_cast_chain_tys<'tcx>(cx: &LateContext<'tcx>, expr: &Expr<'tcx>) -> Optio
         let to_slice_ty = get_raw_slice_ty_mut(cast_to)?;
 
         // If the expression that makes up the source of this cast is itself a cast, recursively
-        // call `expr_cast_chain_tys` and update the end type with the final tartet type.
+        // call `expr_cast_chain_tys` and update the end type with the final target type.
         // Otherwise, this cast is not immediately nested, just construct the info for this cast
         if let Some(prev_info) = expr_cast_chain_tys(cx, cast_expr) {
             Some(CastChainInfo {

clippy_lints/src/casts/mod.rs

@@ -306,7 +306,7 @@ declare_clippy_lint! {
     /// Checks for casts of `&T` to `&mut T` anywhere in the code.
     ///
     /// ### Why is this bad?
-    /// It’s basically guaranteed to be undefined behaviour.
+    /// It’s basically guaranteed to be undefined behavior.
     /// `UnsafeCell` is the only way to obtain aliasable data that is considered
     /// mutable.
     ///

clippy_lints/src/default_union_representation.rs

@@ -25,7 +25,7 @@ declare_clippy_lint! {
     ///
     /// fn main() {
     ///     let _x: u32 = unsafe {
-    ///         Foo { a: 0_i32 }.b // Undefined behaviour: `b` is allowed to be padding
+    ///         Foo { a: 0_i32 }.b // Undefined behavior: `b` is allowed to be padding
     ///     };
     /// }
     /// ```
@@ -39,7 +39,7 @@ declare_clippy_lint! {
     ///
     /// fn main() {
     ///     let _x: u32 = unsafe {
-    ///         Foo { a: 0_i32 }.b // Now defined behaviour, this is just an i32 -> u32 transmute
+    ///         Foo { a: 0_i32 }.b // Now defined behavior, this is just an i32 -> u32 transmute
     ///     };
     /// }
     /// ```

clippy_lints/src/derive.rs

@@ -102,8 +102,8 @@ declare_clippy_lint! {
     /// types.
     ///
     /// ### Why is this bad?
-    /// To avoid surprising behaviour, these traits should
-    /// agree and the behaviour of `Copy` cannot be overridden. In almost all
+    /// To avoid surprising behavior, these traits should
+    /// agree and the behavior of `Copy` cannot be overridden. In almost all
     /// situations a `Copy` type should have a `Clone` implementation that does
     /// nothing more than copy the object, which is what `#[derive(Copy, Clone)]`
     /// gets you.

clippy_lints/src/main_recursion.rs

@@ -12,7 +12,7 @@ declare_clippy_lint! {
     ///
     /// ### Why is this bad?
     /// Apart from special setups (which we could detect following attributes like #![no_std]),
-    /// recursing into main() seems like an unintuitive antipattern we should be able to detect.
+    /// recursing into main() seems like an unintuitive anti-pattern we should be able to detect.
     ///
     /// ### Example
     /// ```no_run

clippy_lints/src/methods/mod.rs

@@ -1563,7 +1563,7 @@ declare_clippy_lint! {
     #[clippy::version = "1.39.0"]
     pub MANUAL_SATURATING_ARITHMETIC,
     style,
-    "`.chcked_add/sub(x).unwrap_or(MAX/MIN)`"
+    "`.checked_add/sub(x).unwrap_or(MAX/MIN)`"
 }
 
 declare_clippy_lint! {

clippy_lints/src/mutable_debug_assertion.rs

@@ -16,7 +16,7 @@ declare_clippy_lint! {
     /// ### Why is this bad?
     /// In release builds `debug_assert!` macros are optimized out by the
     /// compiler.
-    /// Therefore mutating something in a `debug_assert!` macro results in different behaviour
+    /// Therefore mutating something in a `debug_assert!` macro results in different behavior
     /// between a release and debug build.
     ///
     /// ### Example

clippy_lints/src/needless_bitwise_bool.rs

@@ -53,7 +53,7 @@ fn is_bitwise_operation(cx: &LateContext<'_>, expr: &Expr<'_>) -> bool {
     false
 }
 
-fn suggesstion_snippet(cx: &LateContext<'_>, expr: &Expr<'_>) -> Option<String> {
+fn suggestion_snippet(cx: &LateContext<'_>, expr: &Expr<'_>) -> Option<String> {
     if let ExprKind::Binary(ref op, left, right) = expr.kind {
         if let (Some(l_snippet), Some(r_snippet)) = (snippet_opt(cx, left.span), snippet_opt(cx, right.span)) {
             let op_snippet = match op.node {
@@ -75,7 +75,7 @@ impl LateLintPass<'_> for NeedlessBitwiseBool {
                 expr.span,
                 "use of bitwise operator instead of lazy operator between booleans",
                 |diag| {
-                    if let Some(sugg) = suggesstion_snippet(cx, expr) {
+                    if let Some(sugg) = suggestion_snippet(cx, expr) {
                         diag.span_suggestion(expr.span, "try", sugg, Applicability::MachineApplicable);
                     }
                 },

clippy_lints/src/pass_by_ref_or_value.rs

@@ -52,7 +52,7 @@ declare_clippy_lint! {
     /// to a function that needs the memory address. For further details, refer to
     /// [this issue](https://github.com/rust-lang/rust-clippy/issues/5953)
     /// that explains a real case in which this false positive
-    /// led to an **undefined behaviour** introduced with unsafe code.
+    /// led to an **undefined behavior** introduced with unsafe code.
     ///
     /// ### Example
     ///

clippy_lints/src/redundant_clone.rs

@@ -632,7 +632,7 @@ impl<'a, 'tcx> mir::visit::Visitor<'tcx> for PossibleBorrowerVisitor<'a, 'tcx> {
 }
 
 /// Collect possible borrowed for every `&mut` local.
-/// For exampel, `_1 = &mut _2` generate _1: {_2,...}
+/// For example, `_1 = &mut _2` generate _1: {_2,...}
 /// Known Problems: not sure all borrowed are tracked
 struct PossibleOriginVisitor<'a, 'tcx> {
     possible_origin: TransitiveRelation,

clippy_lints/src/transmute/mod.rs

@@ -27,7 +27,7 @@ declare_clippy_lint! {
     /// architecture.
     ///
     /// ### Why is this bad?
-    /// It's basically guaranteed to be undefined behaviour.
+    /// It's basically guaranteed to be undefined behavior.
     ///
     /// ### Known problems
     /// When accessing C, users might want to store pointer
@@ -40,7 +40,7 @@ declare_clippy_lint! {
     #[clippy::version = "pre 1.29.0"]
     pub WRONG_TRANSMUTE,
     correctness,
-    "transmutes that are confusing at best, undefined behaviour at worst and always useless"
+    "transmutes that are confusing at best, undefined behavior at worst and always useless"
 }
 
 // FIXME: Move this to `complexity` again, after #5343 is fixed

doc/adding_lints.md

@@ -28,7 +28,7 @@ because that's clearly a non-descriptive name.
   - [Debugging](#debugging)
   - [PR Checklist](#pr-checklist)
   - [Adding configuration to a lint](#adding-configuration-to-a-lint)
-  - [Cheatsheet](#cheatsheet)
+  - [Cheat Sheet](#cheat-sheet)
 
 ## Setup
 
@@ -649,7 +649,7 @@ in the following steps:
         with the configuration value and a rust file that should be linted by Clippy. The test can
         otherwise be written as usual.
 
-## Cheatsheet
+## Cheat Sheet
 
 Here are some pointers to things you are likely going to need for every lint:
 

tests/ui/blacklisted_name.rs

@@ -46,10 +46,10 @@ fn issue_1647_ref_mut() {
 
 mod tests {
     fn issue_7305() {
-        // `blackisted_name` lint should not be triggered inside of the test code.
+        // `blacklisted_name` lint should not be triggered inside of the test code.
         let foo = 0;
 
-        // Check that even in nested functions warning is still not triggere.
+        // Check that even in nested functions warning is still not triggered.
         fn nested() {
             let foo = 0;
         }