Spellchecking compiler comments

This PR cleans up the rest of the spelling mistakes in the compiler comments. This PR does not change any literal or code spelling issues.

compiler/rustc_resolve/src/diagnostics.rs

@@ -1603,7 +1603,7 @@ impl<'a, 'b> ImportResolver<'a, 'b> {
                 // Remove the `removal_span`.
                 corrections.push((removal_span, "".to_string()));
 
-                // Find the span after the crate name and if it has nested imports immediatately
+                // Find the span after the crate name and if it has nested imports immediately
                 // after the crate name already.
                 //   ie. `use a::b::{c, d};`
                 //               ^^^^^^^^^

compiler/rustc_resolve/src/imports.rs

@@ -74,7 +74,7 @@ crate struct Import<'a> {
     /// In the case where the `Import` was expanded from a "nested" use tree,
     /// this id is the ID of the leaf tree. For example:
     ///
-    /// ```ignore (pacify the mercilous tidy)
+    /// ```ignore (pacify the merciless tidy)
     /// use foo::bar::{a, b}
     /// ```
     ///

compiler/rustc_resolve/src/late/diagnostics.rs

@@ -2151,7 +2151,7 @@ impl<'tcx> LifetimeContext<'_, 'tcx> {
                             // but if we make a mistake elsewhere, mainly by keeping something in
                             // `missing_named_lifetime_spots` that we shouldn't, like associated
                             // `const`s or making a mistake in the AST lowering we would provide
-                            // non-sensical suggestions. Guard against that by skipping these.
+                            // nonsensical suggestions. Guard against that by skipping these.
                             // (#74264)
                             continue;
                         }

compiler/rustc_resolve/src/late/lifetimes.rs

@@ -261,7 +261,7 @@ enum Scope<'a> {
         s: ScopeRef<'a>,
     },
 
-    /// When we have nested trait refs, we concanetate late bound vars for inner
+    /// When we have nested trait refs, we concatenate late bound vars for inner
     /// trait refs from outer ones. But we also need to include any HRTB
     /// lifetimes encountered when identifying the trait that an associated type
     /// is declared on.
@@ -282,8 +282,8 @@ enum BinderScopeType {
     /// Any non-concatenating binder scopes.
     Normal,
     /// Within a syntactic trait ref, there may be multiple poly trait refs that
-    /// are nested (under the `associcated_type_bounds` feature). The binders of
-    /// the innner poly trait refs are extended from the outer poly trait refs
+    /// are nested (under the `associated_type_bounds` feature). The binders of
+    /// the inner poly trait refs are extended from the outer poly trait refs
     /// and don't increase the late bound depth. If you had
     /// `T: for<'a>  Foo<Bar: for<'b> Baz<'a, 'b>>`, then the `for<'b>` scope
     /// would be `Concatenating`. This also used in trait refs in where clauses
@@ -2930,7 +2930,7 @@ impl<'a, 'tcx> LifetimeContext<'a, 'tcx> {
                 path_span: Span,
                 generic_args: &'v hir::GenericArgs<'v>,
             ) {
-                // parenthesized args enter a new elison scope
+                // parenthesized args enter a new elision scope
                 if generic_args.parenthesized {
                     return;
                 }

compiler/rustc_resolve/src/lib.rs

@@ -506,7 +506,7 @@ impl ModuleKind {
 /// program) if all but one of them come from glob imports.
 #[derive(Copy, Clone, PartialEq, Eq, Hash, Debug)]
 struct BindingKey {
-    /// The identifier for the binding, aways the `normalize_to_macros_2_0` version of the
+    /// The identifier for the binding, always the `normalize_to_macros_2_0` version of the
     /// identifier.
     ident: Ident,
     ns: Namespace,

compiler/rustc_resolve/src/macros.rs

@@ -69,7 +69,7 @@ pub enum MacroRulesScope<'a> {
 /// The reason is that we update scopes with value `MacroRulesScope::Invocation(invoc_id)`
 /// in-place after `invoc_id` gets expanded.
 /// This helps to avoid uncontrollable growth of `macro_rules!` scope chains,
-/// which usually grow lineraly with the number of macro invocations
+/// which usually grow linearly with the number of macro invocations
 /// in a module (including derives) and hurt performance.
 pub(crate) type MacroRulesScopeRef<'a> = Interned<'a, Cell<MacroRulesScope<'a>>>;