Fix more “a”/“an” typos

clippy_lints/src/formatting.rs

@@ -164,7 +164,7 @@ fn check_unop(cx: &EarlyContext<'_>, expr: &Expr) {
         if !differing_macro_contexts(lhs.span, rhs.span) && !lhs.span.from_expansion();
         // span between BinOp LHS and RHS
         let binop_span = lhs.span.between(rhs.span);
-        // if RHS is a UnOp
+        // if RHS is an UnOp
         if let ExprKind::Unary(op, ref un_rhs) = rhs.kind;
         // from UnOp operator to UnOp operand
         let unop_operand_span = rhs.span.until(un_rhs.span);

clippy_lints/src/non_copy_const.rs

@@ -122,7 +122,7 @@ fn is_unfrozen<'tcx>(cx: &LateContext<'tcx>, ty: Ty<'tcx>) -> bool {
     // Ignore types whose layout is unknown since `is_freeze` reports every generic types as `!Freeze`,
     // making it indistinguishable from `UnsafeCell`. i.e. it isn't a tool to prove a type is
     // 'unfrozen'. However, this code causes a false negative in which
-    // a type contains a layout-unknown type, but also a unsafe cell like `const CELL: Cell<T>`.
+    // a type contains a layout-unknown type, but also an unsafe cell like `const CELL: Cell<T>`.
     // Yet, it's better than `ty.has_type_flags(TypeFlags::HAS_TY_PARAM | TypeFlags::HAS_PROJECTION)`
     // since it works when a pointer indirection involves (`Cell<*const T>`).
     // Making up a `ParamEnv` where every generic params and assoc types are `Freeze`is another option;
@@ -266,7 +266,7 @@ impl<'tcx> LateLintPass<'tcx> for NonCopyConst {
                 // in other words, lint consts whose value *could* be unfrozen, not definitely is.
                 // This feels inconsistent with how the lint treats generic types,
                 // which avoids linting types which potentially become unfrozen.
-                // One could check whether a unfrozen type have a *frozen variant*
+                // One could check whether an unfrozen type have a *frozen variant*
                 // (like `body_id_opt.map_or_else(|| !has_frozen_variant(...), ...)`),
                 // and do the same as the case of generic types at impl items.
                 // Note that it isn't sufficient to check if it has an enum