Auto merge of rust-lang#147826 - Muscraft:update-typos, r=Noratrieb

Update typos

I saw that `typos` was a few versions out of date and figured it would be a good idea to update it. Upgrading to `1.38.1` adds the [July](crate-ci/typos#1331), [August](crate-ci/typos#1345), and [September](crate-ci/typos#1370) dictionary updates. As part of this change, I also sorted the configuration file.

Author: bors

compiler/rustc_builtin_macros/messages.ftl

@@ -283,7 +283,7 @@ builtin_macros_requires_cfg_pattern =
     macro requires a cfg-pattern as an argument
     .label = cfg-pattern required
 
-builtin_macros_source_uitls_expected_item = expected item, found `{$token}`
+builtin_macros_source_utils_expected_item = expected item, found `{$token}`
 
 builtin_macros_takes_no_arguments = {$name} takes no arguments
 

compiler/rustc_builtin_macros/src/errors.rs

@@ -952,7 +952,7 @@ pub(crate) struct AttributeOnlyUsableWithCrateType<'a> {
 }
 
 #[derive(Diagnostic)]
-#[diag(builtin_macros_source_uitls_expected_item)]
+#[diag(builtin_macros_source_utils_expected_item)]
 pub(crate) struct ExpectedItem<'a> {
     #[primary_span]
     pub span: Span,

compiler/rustc_codegen_llvm/src/back/write.rs

@@ -342,7 +342,7 @@ fn write_bitcode_to_file(module: &ModuleCodegen<ModuleLlvm>, path: &Path) {
     }
 }
 
-/// In what context is a dignostic handler being attached to a codegen unit?
+/// In what context is a diagnostic handler being attached to a codegen unit?
 pub(crate) enum CodegenDiagnosticsStage {
     /// Prelink optimization stage.
     Opt,

compiler/rustc_const_eval/src/interpret/call.rs

@@ -127,7 +127,7 @@ impl<'tcx, M: Machine<'tcx>> InterpCx<'tcx, M> {
         } else if all_fields_1zst(def.variant(var1))? {
             def.variant(var0)
         } else {
-            // No varant is all-1-ZST, so no NPO.
+            // No variant is all-1-ZST, so no NPO.
             return interp_ok(layout);
         };
         // The "relevant" variant must have exactly one field, and its type is the "inner" type.

compiler/rustc_const_eval/src/interpret/projection.rs

@@ -2,7 +2,7 @@
 //!
 //! OpTy and PlaceTy generally work by "let's see if we are actually an MPlaceTy, and do something custom if not".
 //! For PlaceTy, the custom thing is basically always to call `force_allocation` and then use the MPlaceTy logic anyway.
-//! For OpTy, the custom thing on field pojections has to be pretty clever (since `Operand::Immediate` can have fields),
+//! For OpTy, the custom thing on field projections has to be pretty clever (since `Operand::Immediate` can have fields),
 //! but for array/slice operations it only has to worry about `Operand::Uninit`. That makes the value part trivial,
 //! but we still need to do bounds checking and adjust the layout. To not duplicate that with MPlaceTy, we actually
 //! implement the logic on OpTy, and MPlaceTy calls that.

compiler/rustc_const_eval/src/interpret/util.rs

@@ -74,7 +74,7 @@ impl EnteredTraceSpan for tracing::span::EnteredSpan {
     }
 }
 
-/// Shortand for calling [crate::interpret::Machine::enter_trace_span] on a [tracing::info_span!].
+/// Shorthand for calling [crate::interpret::Machine::enter_trace_span] on a [tracing::info_span!].
 /// This is supposed to be compiled out when [crate::interpret::Machine::enter_trace_span] has the
 /// default implementation (i.e. when it does not actually enter the span but instead returns `()`).
 /// This macro takes a type implementing the [crate::interpret::Machine] trait as its first argument

compiler/rustc_hir_typeck/src/method/suggest.rs

@@ -557,10 +557,10 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> {
                     }
                 }
 
-                // If the shadowed binding has an itializer expression,
+                // If the shadowed binding has an initializer expression,
                 // use the initializer expression's ty to try to find the method again.
                 // For example like:  `let mut x = Vec::new();`,
-                // `Vec::new()` is the itializer expression.
+                // `Vec::new()` is the initializer expression.
                 if let Some(self_ty) = self.fcx.node_ty_opt(binding.init_hir_id)
                     && self
                         .fcx

compiler/rustc_lint/src/builtin.rs

@@ -2959,7 +2959,7 @@ impl<'tcx> LateLintPass<'tcx> for AsmLabels {
 
                         for c in chars {
                             // Inside a template format arg, any character is permitted for the
-                            // puproses of label detection because we assume that it can be
+                            // purposes of label detection because we assume that it can be
                             // replaced with some other valid label string later. `options(raw)`
                             // asm blocks cannot have format args, so they are excluded from this
                             // special case.

compiler/rustc_next_trait_solver/src/solve/eval_ctxt/mod.rs

@@ -980,7 +980,7 @@ where
         }
     }
 
-    /// This sohuld only be used when we're either instantiating a previously
+    /// This should only be used when we're either instantiating a previously
     /// unconstrained "return value" or when we're sure that all aliases in
     /// the types are rigid.
     #[instrument(level = "trace", skip(self, param_env), ret)]

compiler/rustc_next_trait_solver/src/solve/mod.rs

@@ -39,7 +39,7 @@ use crate::solve::assembly::Candidate;
 ///
 /// We previously used  `cx.recursion_limit().0.checked_ilog2().unwrap_or(0)` for this.
 /// However, it feels unlikely that uncreasing the recursion limit by a power of two
-/// to get one more itereation is every useful or desirable. We now instead used a constant
+/// to get one more iteration is every useful or desirable. We now instead used a constant
 /// here. If there ever ends up some use-cases where a bigger number of fixpoint iterations
 /// is required, we can add a new attribute for that or revert this to be dependant on the
 /// recursion limit again. However, this feels very unlikely.