From 842bf71fdad1aaf6d56deff86beac97ece148355 Mon Sep 17 00:00:00 2001
From: James R T <jamestiotio@gmail.com>
Date: Tue, 11 Jan 2022 10:42:51 +0800
Subject: [PATCH] fix(compiler): correct minor typos in some long error code
 explanations

---
 compiler/rustc_error_codes/src/error_codes/E0038.md | 4 ++--
 compiler/rustc_error_codes/src/error_codes/E0183.md | 4 ++--
 compiler/rustc_error_codes/src/error_codes/E0521.md | 2 +-
 compiler/rustc_error_codes/src/error_codes/E0581.md | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/compiler/rustc_error_codes/src/error_codes/E0038.md b/compiler/rustc_error_codes/src/error_codes/E0038.md
index ca2eaa54057fa..584b78554ef88 100644
--- a/compiler/rustc_error_codes/src/error_codes/E0038.md
+++ b/compiler/rustc_error_codes/src/error_codes/E0038.md
@@ -15,7 +15,7 @@ Two general aspects of trait object types give rise to the restrictions:
      these types can only be accessed through pointers, such as `&dyn Trait` or
      `Box<dyn Trait>`. The size of such a pointer is known, but the size of the
      `dyn Trait` object pointed-to by the pointer is _opaque_ to code working
-     with it, and different tait objects with the same trait object type may
+     with it, and different trait objects with the same trait object type may
      have different sizes.
 
   2. The pointer used to access a trait object is paired with an extra pointer
@@ -167,7 +167,7 @@ implementation on-demand. If you call `foo()` with a `bool` parameter, the
 compiler will only generate code for `foo::<bool>()`. When we have additional
 type parameters, the number of monomorphized implementations the compiler
 generates does not grow drastically, since the compiler will only generate an
-implementation if the function is called with unparametrized substitutions
+implementation if the function is called with unparameterized substitutions
 (i.e., substitutions where none of the substituted types are themselves
 parameterized).
 
diff --git a/compiler/rustc_error_codes/src/error_codes/E0183.md b/compiler/rustc_error_codes/src/error_codes/E0183.md
index 7e1d08daae1f2..92fa4c7c21e72 100644
--- a/compiler/rustc_error_codes/src/error_codes/E0183.md
+++ b/compiler/rustc_error_codes/src/error_codes/E0183.md
@@ -1,4 +1,4 @@
-Manual implemetation of a `Fn*` trait.
+Manual implementation of a `Fn*` trait.
 
 Erroneous code example:
 
@@ -33,7 +33,7 @@ impl FnOnce<()> for MyClosure {  // ok!
 }
 ```
 
-The argumements must be a tuple representing the argument list.
+The arguments must be a tuple representing the argument list.
 For more info, see the [tracking issue][iss29625]:
 
 [iss29625]: https://github.com/rust-lang/rust/issues/29625
diff --git a/compiler/rustc_error_codes/src/error_codes/E0521.md b/compiler/rustc_error_codes/src/error_codes/E0521.md
index 65dcac983acd5..fedf6365fb559 100644
--- a/compiler/rustc_error_codes/src/error_codes/E0521.md
+++ b/compiler/rustc_error_codes/src/error_codes/E0521.md
@@ -10,7 +10,7 @@ let _add = |el: &str| {
 };
 ```
 
-A type anotation of a closure parameter implies a new lifetime declaration.
+A type annotation of a closure parameter implies a new lifetime declaration.
 Consider to drop it, the compiler is reliably able to infer them.
 
 ```
diff --git a/compiler/rustc_error_codes/src/error_codes/E0581.md b/compiler/rustc_error_codes/src/error_codes/E0581.md
index 89f6e3269ec36..02468dd946646 100644
--- a/compiler/rustc_error_codes/src/error_codes/E0581.md
+++ b/compiler/rustc_error_codes/src/error_codes/E0581.md
@@ -10,7 +10,7 @@ fn main() {
 }
 ```
 
-The problem here is that the lifetime isn't contrained by any of the arguments,
+The problem here is that the lifetime isn't constrained by any of the arguments,
 making it impossible to determine how long it's supposed to live.
 
 To fix this issue, either use the lifetime in the arguments, or use the