Merge pull request #3584 from pengqiseven/master

remove repetitive words

Author: ehuss

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 to 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 that 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}",

text/2957-cargo-features2.md

@@ -216,7 +216,7 @@ command-line.
 * Features listed in the `--features` flag no longer pay attention to the
   package in the current directory. Instead, it only enables the given
   features for the selected packages. Additionally, the features are enabled
-  only if the the package defines the given features.
+  only if the package defines the given features.
 
   For example:
 

text/3127-trim-paths.md

@@ -157,7 +157,7 @@ If `trim-paths` is `none` (`false`), no extra flag is supplied to `rustc`.
 
 If `trim-paths` is anything else, then its value is supplied directly to `rustc`'s `--remap-path-scope` option, along with two `--remap-path-prefix` arguments:
 - From the path of the local sysroot to `/rustc/[commit hash]`. 
-- For the the current package (where the current working directory is in), from the the absolute path of the package root to empty string.
+- For the current package (where the current working directory is in), from the absolute path of the package root to empty string.
   For other packages, from the absolute path of the package root to `[package name]-[package version]`.
 
 The default value of `trim-paths` is `object` for release profile. As a result, panic messages (which are always embedded) are sanitised. If debug information is embedded, then they are sanitised; if they are split then they are kept untouched, but the paths to these split files are sanitised.

text/3308-offset_of.md

@@ -539,7 +539,7 @@ such as in the case of the last field in `(Foo, dyn SomeTrait)`, where the
 offset depends on what the concrete type is. Notably, the compiler must read the
 alignment out of the vtable when you access such a field.
 
-This is equivalent to not being able to determine the the size and/or alignment
+This is equivalent to not being able to determine the size and/or alignment
 of `?Sized` types, where we solve it by making the user provide the instance
 they're interested in, as in `core::mem::{size_of_val, align_of_val}`, so we
 could provide an analogous `core::mem::offset_of_val!($val, $Type, $field)` to