remove repetitive words

Signed-off-by: pengqiseven <912170095@qq.com>

Author: pengqiseven

text/0458-send-improvements.md

@@ -75,7 +75,7 @@ This leads us to our second refinement.  We add the rule that `&T` is `Send` if
 `T` is `Sync`--in other words, we disallow `Send`ing shared references with a
 non-threadsafe interior.  We do, however, still allow `&mut T` where `T` is `Send`, even
 if it is not `Sync`.  This is safe because `&mut T` linearizes access--the only way to
-access the the original data is through the unique reference, so it is safe to send to other
+access the original data is through the unique reference, so it is safe to send to other
 threads.  Similarly, we allow `&T` where `T` is `Sync`, even if it is not `Send`, since by the definition of `Sync` `&T` is already known to be threadsafe.
 
 Note that this definition of `Send` is identical to the old definition of `Send` when

text/1214-projections-lifetimes-and-wf.md

@@ -259,7 +259,7 @@ Here, the WF criteria for `DeltaMap<K,V>` are as follows:
 - `V: Sized`, because of the implicit `Sized` bound
 
 Let's look at those `K:'a` bounds a bit more closely. If you leave
-them out, you will find that the the structure definition above does
+them out, you will find that the structure definition above does
 not type-check. This is due to the requirement that the types of all
 fields in a structure definition must be well-formed.  In this case,
 the field `base_map` has the type `&'a mut HashMap<K,V>`, and this
@@ -794,7 +794,7 @@ The object type rule is similar, though it includes an extra clause:
       R ⊢ O0..On+r WF
 
 The first two clauses here state that the explicit lifetime bound `r`
-must be an approximation for the the implicit bounds `rᵢ` derived from
+must be an approximation for the implicit bounds `rᵢ` derived from
 the trait definitions. That is, if you have a trait definition like
 
 ```rust

text/1252-open-options.md

@@ -56,7 +56,7 @@ time. No guarantees are made about the order writes end up in the file though.
 Note: sadly append-mode is not atomic on NFS filesystems.
 
 One maybe obvious note when using append-mode: make sure that all data that
-belongs together, is written the the file in one operation. This can be done
+belongs together, is written the file in one operation. This can be done
 by concatenating strings before passing them to `write()`, or using a buffered
 writer (with a more than adequately sized buffer) and calling `flush()` when the
 message is complete.

text/1721-crt-static.md

@@ -193,7 +193,7 @@ the MSVC target with `/MD`, indicating dynamic linkage. Otherwise if the value
 is `static` it will compile code with `/MT`, indicating static linkage. Because
 today the MSVC targets use dynamic linkage and gcc-rs compiles C code with `/MD`,
 gcc-rs will remain forward and backwards compatible with existing and future
-Rust MSVC toolchains until such time as the the decision is made to change the
+Rust MSVC toolchains until such time as the decision is made to change the
 MSVC toolchain to `+crt-static` by default.
 
 ### Lazy link attributes

text/1892-uninitialized-uninhabited.md

@@ -207,7 +207,7 @@ impl<T> MaybeUninit<T> {
     ///
     /// # Unsafety
     ///
-    /// It is up to the caller to guarantee that the the `MaybeUninit` really is in an initialized
+    /// It is up to the caller to guarantee that the `MaybeUninit` really is in an initialized
     /// state, otherwise this will immediately cause undefined behavior.
     pub unsafe fn into_inner(self) -> T {
         std::ptr::read(&*self.value)
@@ -217,7 +217,7 @@ impl<T> MaybeUninit<T> {
     ///
     /// # Unsafety
     ///
-    /// It is up to the caller to guarantee that the the `MaybeUninit` really is in an initialized
+    /// It is up to the caller to guarantee that the `MaybeUninit` really is in an initialized
     /// state, otherwise this will immediately cause undefined behavior.
     pub unsafe fn get_ref(&self) -> &T {
         &*self.value
@@ -227,7 +227,7 @@ impl<T> MaybeUninit<T> {
     ///
     /// # Unsafety
     ///
-    /// It is up to the caller to guarantee that the the `MaybeUninit` really is in an initialized
+    /// It is up to the caller to guarantee that the `MaybeUninit` really is in an initialized
     /// state, otherwise this will immediately cause undefined behavior.
     pub unsafe fn get_mut(&mut self) -> &mut T {
         &mut *self.value

text/2027-object_safe_for_dispatch.md

@@ -83,7 +83,7 @@ dispatch.
 [how-we-teach-this]: #how-we-teach-this
 
 This is just a slight tweak to how object safety is implemented. We will need
-to make sure the the official documentation is accurate to the rules,
+to make sure the official documentation is accurate to the rules,
 especially the reference.
 
 However, this does not need to be **highlighted** to users per se in the

text/2044-license-rfcs.md

@@ -21,7 +21,7 @@ This RFC is not authored by a lawyer, so its reasoning may be wrong.
 Currently, the Rust RFCs repo is in a state where no clear open source license
 is specified.
 
-The current legal base of the the RFCs repo is the "License Grant to Other
+The current legal base of the RFCs repo is the "License Grant to Other
 Users" from the [Github ToS]`*`:
 
 ```

text/2226-fmt-debug-hex.md

@@ -136,7 +136,7 @@ This is fixed by [PR #46233](https://github.com/rust-lang/rust/pull/46233).
 # Drawbacks
 [drawbacks]: #drawbacks
 
-The hexadecimal flag in the the `Debug` trait is superficially redundant
+The hexadecimal flag in the `Debug` trait is superficially redundant
 with the `LowerHex` and `UpperHex` traits.
 If these traits were not stable yet, we could have considered a more unified design.
 

text/2535-or-patterns.md

@@ -764,7 +764,7 @@ following operations (where `a`, `b`, and `c` are arbitrary regexes):
 + Grouping: used to define the scope of what operators apply to.
   Commonly written as `(a)`.
 
-Formally, the the minimal formalism we need is:
+Formally, the minimal formalism we need is:
 
 ```rust
 pat : terminal | pat pat | pat "|" pat | "(" pat ")" ;

text/2795-format-args-implicit-identifiers.md

@@ -218,7 +218,7 @@ There are two types of arguments `format_args!` can accept:
 
        format_args!("The {}'s name is {}.", species, name)
 
-2. Named arguments, which require more typing but (in the RFC author's experience) have the upside that the the format string itself is easier to read:
+2. Named arguments, which require more typing but (in the RFC author's experience) have the upside that the format string itself is easier to read:
 
        format_args!(
            "The {species}'s name is {name}",