Auto merge of rust-lang#140935 - omahs:patch-5, r=jieyouxu

Fix typos

Fix typos

Author: bors

compiler/rustc_ast_lowering/src/lib.rs

@@ -896,7 +896,7 @@ impl<'a, 'hir> LoweringContext<'a, 'hir> {
             let ret = self.arena.alloc_from_iter(lowered_attrs);
 
             // this is possible if an item contained syntactical attribute,
-            // but none of them parse succesfully or all of them were ignored
+            // but none of them parse successfully or all of them were ignored
             // for not being built-in attributes at all. They could be remaining
             // unexpanded attributes used as markers in proc-macro derives for example.
             // This will have emitted some diagnostics for the misparse, but will then

compiler/rustc_codegen_ssa/src/codegen_attrs.rs

@@ -387,7 +387,7 @@ fn codegen_fn_attrs(tcx: TyCtxt<'_>, did: LocalDefId) -> CodegenFnAttrs {
                                 [sym::arm, sym::a32 | sym::t32]
                                     if !tcx.sess.target.has_thumb_interworking =>
                                 {
-                                    tcx.dcx().emit_err(errors::UnsuportedInstructionSet {
+                                    tcx.dcx().emit_err(errors::UnsupportedInstructionSet {
                                         span: attr.span(),
                                     });
                                     None

compiler/rustc_codegen_ssa/src/errors.rs

@@ -149,7 +149,7 @@ pub(crate) struct NullOnExport {
 
 #[derive(Diagnostic)]
 #[diag(codegen_ssa_unsupported_instruction_set, code = E0779)]
-pub(crate) struct UnsuportedInstructionSet {
+pub(crate) struct UnsupportedInstructionSet {
     #[primary_span]
     pub span: Span,
 }

compiler/rustc_hir_analysis/messages.ftl

@@ -522,7 +522,7 @@ hir_analysis_trait_object_declared_with_no_traits =
     at least one trait is required for an object type
     .alias_span = this alias does not contain a trait
 
-hir_analysis_traits_with_defualt_impl = traits with a default impl, like `{$traits}`, cannot be implemented for {$problematic_kind} `{$self_ty}`
+hir_analysis_traits_with_default_impl = traits with a default impl, like `{$traits}`, cannot be implemented for {$problematic_kind} `{$self_ty}`
     .note = a trait object implements `{$traits}` if and only if `{$traits}` is one of the trait object's trait bounds
 
 hir_analysis_transparent_enum_variant = transparent enum needs exactly one variant, but has {$number}

compiler/rustc_hir_analysis/src/errors.rs

@@ -1327,7 +1327,7 @@ pub(crate) struct ImplForTyRequires {
 }
 
 #[derive(Diagnostic)]
-#[diag(hir_analysis_traits_with_defualt_impl, code = E0321)]
+#[diag(hir_analysis_traits_with_default_impl, code = E0321)]
 #[note]
 pub(crate) struct TraitsWithDefaultImpl<'a> {
     #[primary_span]

compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs

@@ -2339,7 +2339,7 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> {
                 }
 
                 if !mismatched_params.is_empty() {
-                    // For each mismatched paramter, create a two-way link to each matched parameter
+                    // For each mismatched parameter, create a two-way link to each matched parameter
                     // of the same type.
                     let mut dependants = IndexVec::<ExpectedIdx, _>::from_fn_n(
                         |_| SmallVec::<[u32; 4]>::new(),

compiler/rustc_interface/src/passes.rs

@@ -907,7 +907,7 @@ pub fn create_and_enter_global_ctxt<T, F: for<'tcx> FnOnce(TyCtxt<'tcx>) -> T>(
                 feed.output_filenames(Arc::new(outputs));
 
                 let res = f(tcx);
-                // FIXME maybe run finish even when a fatal error occured? or at least tcx.alloc_self_profile_query_strings()?
+                // FIXME maybe run finish even when a fatal error occurred? or at least tcx.alloc_self_profile_query_strings()?
                 tcx.finish();
                 res
             },

compiler/rustc_macros/src/symbols.rs

@@ -299,7 +299,7 @@ fn symbols_with_errors(input: TokenStream) -> (TokenStream, Vec<syn::Error>) {
     let output = quote! {
         const SYMBOL_DIGITS_BASE: u32 = #symbol_digits_base;
 
-        /// The number of predefined symbols; this is the the first index for
+        /// The number of predefined symbols; this is the first index for
         /// extra pre-interned symbols in an Interner created via
         /// [`Interner::with_extra_symbols`].
         pub const PREDEFINED_SYMBOLS_COUNT: u32 = #predefined_symbols_count;

compiler/rustc_mir_build/src/builder/scope.rs

@@ -1485,7 +1485,7 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
 ///   panic occurred (a subset of the drops in `scope`, since we sometimes elide StorageDead and other
 ///   instructions on unwinding)
 /// * `dropline_to`, describes the drops that would occur at this point in the code if a
-///    coroutine drop occured.
+///    coroutine drop occurred.
 /// * `storage_dead_on_unwind`, if true, then we should emit `StorageDead` even when unwinding
 /// * `arg_count`, number of MIR local variables corresponding to fn arguments (used to assert that we don't drop those)
 fn build_scope_drops<'tcx, F>(

compiler/rustc_next_trait_solver/src/solve/assembly/structural_traits.rs

@@ -945,7 +945,7 @@ where
 
         // This is quite similar to the `projection_may_match` we use in unsizing,
         // but here we want to unify a projection predicate against an alias term
-        // so we can replace it with the the projection predicate's term.
+        // so we can replace it with the projection predicate's term.
         let mut matching_projections = replacements
             .iter()
             .filter(|source_projection| self.projection_may_match(**source_projection, alias_term));

compiler/rustc_trait_selection/src/error_reporting/traits/on_unimplemented_format.rs

@@ -20,7 +20,7 @@ pub struct FormatString {
     input: Symbol,
     span: Span,
     pieces: Vec<Piece>,
-    /// The formatting string was parsed succesfully but with warnings
+    /// The formatting string was parsed successfully but with warnings
     pub warnings: Vec<FormatWarning>,
 }
 

src/doc/rustc-dev-guide/src/autodiff/installation.md

@@ -1,6 +1,6 @@
 # Installation
 
-In the near future, `std::autodiff` should become available in nightly builds for users. As a contribute however, you will still need to build rustc from source. Please be aware that the msvc target is not supported at the moment, all other tier 1 targets should work. Please open an issue if you encounter any problems on a supported tier 1 target, or if you succesfully build this project on a tier2/tier3 target.
+In the near future, `std::autodiff` should become available in nightly builds for users. As a contributor however, you will still need to build rustc from source. Please be aware that the msvc target is not supported at the moment, all other tier 1 targets should work. Please open an issue if you encounter any problems on a supported tier 1 target, or if you successfully build this project on a tier2/tier3 target.
 
 ## Build instructions
 

src/doc/rustc-dev-guide/src/rustdoc-internals/rustdoc-test-suite.md

@@ -16,10 +16,10 @@ In addition to the directives listed here,
 `rustdoc` tests also support most
 [compiletest directives](../tests/directives.html).
 
-All `PATH`s in directives are relative to the the rustdoc output directory (`build/TARGET/test/rustdoc/TESTNAME`),
+All `PATH`s in directives are relative to the rustdoc output directory (`build/TARGET/test/rustdoc/TESTNAME`),
 so it is conventional to use a `#![crate_name = "foo"]` attribute to avoid
 having to write a long crate name multiple times.
-To avoid repetion, `-` can be used in any `PATH` argument to re-use the previous `PATH` argument.
+To avoid repetition, `-` can be used in any `PATH` argument to re-use the previous `PATH` argument.
 
 All arguments take the form of quoted strings
 (both single and double quotes are supported),
@@ -87,7 +87,7 @@ compiletest's `--bless` flag is forwarded to htmldocck.
 
 Usage: `//@ has-dir PATH`
 
-Checks for the existance of directory `PATH`.
+Checks for the existence of directory `PATH`.
 
 ### `files`
 
@@ -106,7 +106,7 @@ Example: `//@ files "foo/bar" '["index.html", "sidebar-items.js"]'`
 ## Limitations
 `htmldocck.py` uses the xpath implementation from the standard library.
 This leads to several limitations:
-* All `XPATH` arguments must start with `//` due to a flaw in the implemention.
+* All `XPATH` arguments must start with `//` due to a flaw in the implementation.
 * Many XPath features (functions, axies, etc.) are not supported.
 * Only well-formed HTML can be parsed (hopefully rustdoc doesn't output mismatched tags).
 

src/doc/rustc-dev-guide/src/type-checking.md

@@ -17,7 +17,7 @@ Type "collection" is the process of converting the types found in the HIR
 **internal representation** used by the compiler (`Ty<'tcx>`) – we also do
 similar conversions for where-clauses and other bits of the function signature.
 
-To try and get a sense for the difference, consider this function:
+To try and get a sense of the difference, consider this function:
 
 ```rust,ignore
 struct Foo { }

src/doc/rustc-dev-guide/src/type-inference.md

@@ -19,7 +19,7 @@ Here, the type of `things` is *inferred* to be `Vec<&str>` because of the value
 we push into `things`.
 
 The type inference is based on the standard Hindley-Milner (HM) type inference
-algorithm, but extended in various way to accommodate subtyping, region
+algorithm, but extended in various ways to accommodate subtyping, region
 inference, and higher-ranked types.
 
 ## A note on terminology

src/doc/rustc-dev-guide/src/typing_parameter_envs.md

@@ -4,7 +4,7 @@
 
 ## Typing Environments
 
-When interacting with the type system there are a few variables to consider that can affect the results of trait solving. The the set of in-scope where clauses, and what phase of the compiler type system operations are being performed in (the [`ParamEnv`][penv] and [`TypingMode`][tmode] structs respectively).
+When interacting with the type system there are a few variables to consider that can affect the results of trait solving. The set of in-scope where clauses, and what phase of the compiler type system operations are being performed in (the [`ParamEnv`][penv] and [`TypingMode`][tmode] structs respectively).
 
 When an environment to perform type system operations in has not yet been created, the [`TypingEnv`][tenv] can be used to bundle all of the external context required into a single type.
 
@@ -13,11 +13,11 @@ Once a context to perform type system operations in has been created (e.g. an [`
 [ocx]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/traits/struct.ObligationCtxt.html
 [fnctxt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/fn_ctxt/struct.FnCtxt.html
 
-## Parameter Environemnts
+## Parameter Environments
 
 ### What is a `ParamEnv`
 
-The [`ParamEnv`][penv] is a list of in-scope where-clauses, it typically corresponds to a specific item's where clauses. Some clauses are not explicitly written but are instead are implicitly added in the [`predicates_of`][predicates_of] query, such as `ConstArgHasType` or (some) implied bounds.
+The [`ParamEnv`][penv] is a list of in-scope where-clauses, it typically corresponds to a specific item's where clauses. Some clauses are not explicitly written but are instead implicitly added in the [`predicates_of`][predicates_of] query, such as `ConstArgHasType` or (some) implied bounds.
 
 In most cases `ParamEnv`s are initially created via the [`param_env` query][query] which returns a `ParamEnv` derived from the provided item's where clauses. A `ParamEnv` can also be created with arbitrary sets of clauses that are not derived from a specific item, such as in [`compare_method_predicate_entailment`][method_pred_entailment] where we create a hybrid `ParamEnv` consisting of the impl's where clauses and the trait definition's function's where clauses.
 
@@ -73,7 +73,7 @@ fn foo2<T>(a: T) {
 
 ### Acquiring a `ParamEnv`
 
-Using the wrong [`ParamEnv`][penv] when interacting with the type system can lead to ICEs, illformed programs compiling, or erroing when we shouldn't. See [#82159](https://github.com/rust-lang/rust/pull/82159) and [#82067](https://github.com/rust-lang/rust/pull/82067) as examples of PRs that modified the compiler to use the correct param env and in the process fixed ICEs.
+Using the wrong [`ParamEnv`][penv] when interacting with the type system can lead to ICEs, illformed programs compiling, or erroring when we shouldn't. See [#82159](https://github.com/rust-lang/rust/pull/82159) and [#82067](https://github.com/rust-lang/rust/pull/82067) as examples of PRs that modified the compiler to use the correct param env and in the process fixed ICEs.
 
 In the large majority of cases, when a `ParamEnv` is required it either already exists somewhere in scope, or above in the call stack and should be passed down. A non exhaustive list of places where you might find an existing `ParamEnv`:
 - During typeck `FnCtxt` has a [`param_env` field][fnctxt_param_env]

src/doc/rustc/src/platform-support/xtensa.md

@@ -24,4 +24,4 @@ Xtensa targets that support `std` are documented in the [ESP-IDF platform suppor
 
 ## Building the targets
 
-The targets can be built by installing the [Xtensa enabled Rust channel](https://github.com/esp-rs/rust/). See instructions in the [RISC-V and Xtensa Targets section of the The Rust on ESP Book](https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html).
+The targets can be built by installing the [Xtensa enabled Rust channel](https://github.com/esp-rs/rust/). See instructions in the [RISC-V and Xtensa Targets section of The Rust on ESP Book](https://docs.esp-rs.org/book/installation/riscv-and-xtensa.html).