Merge pull request #3613 from growfrow/master

chore: remove repetitive words

text/1298-incremental-compilation.md

@@ -149,7 +149,7 @@ saved. The effect of saving fewer things (such as only saving object
 code) will simply be to make incremental compilation somewhat less
 effective, since we will be forced to re-type-check and re-trans
 functions where we might have gotten away with only generating new
-object code. However, this is expected to be be a second order effect
+object code. However, this is expected to be a second order effect
 overall, particularly since LLVM optimization time can be a very large
 portion of compilation.
 

text/1398-kinds-of-allocators.md

@@ -917,7 +917,7 @@ comes, it may come with a new trait (call it `GcAwareAllocator`).
    option we choose can be incorporated into the meta-data for a
    crate.)
 
-Allocators that are are GC-compatible have to explicitly declare
+Allocators that are GC-compatible have to explicitly declare
 themselves as such, by implementing `GcAwareAllocator`, which will
 then impose new conditions on the methods of `Allocator`, for example
 ensuring e.g. that allocated blocks of memory can be scanned

text/2091-inline-semantic.md

@@ -330,7 +330,7 @@ information in such a strange way. There are two restrictions that force us to a
     solution for systems languages like Rust because optimization often collapses multiple levels
     of function calls.  In some embedded systems, the backtrace may even be unavailable!
 
-2. Solutions that use default function arguments alongside normal arguments are are often used in
+2. Solutions that use default function arguments alongside normal arguments are often used in
     languages that do not perform inference higher than statement level, e.g. Swift and C#. Rust
     does not (yet) support default function arguments or function overloading because they interfere
     with type inference, so such solutions are ruled out.

text/2203-const-repeat-expr.md

@@ -175,7 +175,7 @@ argues that the change is quite intuitive.
 
 The alternative, in addition to simply not doing this, is to modify a host of
 other constructs such as [`mem::uninitialized()`], for loops over iterators,
-[`ptr::write`] to be `const`, which is is a larger change. The design offered by
+[`ptr::write`] to be `const`, which is a larger change. The design offered by
 this RFC is therefore the simplest and most non-intrusive design. It is also
 the most consistent.
 

text/2585-unsafe-block-in-unsafe-fn.md

@@ -164,7 +164,7 @@ fn` for functions that are "unsafe to call" but do not implicitly have an
 trait` for traits, though the behavior would be the same as `unsafe trait`.
 
 We could introduce named proof obligations (proposed by @Centril) such that the
-compiler can be be told (to some extend) if the assumptions made by the `unsafe
+compiler can be told (to some extend) if the assumptions made by the `unsafe
 fn` are sufficient to discharge the requirements of the unsafe operations.
 
 We could restrict this requirement to use `unsafe` blocks in `unsafe fn` to

text/2603-rust-symbol-name-mangling-v0.md

@@ -348,7 +348,7 @@ and `NCNvNtC7mycrate3foo3bars_0` respectively.
 Methods are nested within `impl` or `trait` items. As such it would be
 possible to construct their symbol names as paths like
 `my_crate::foo::{{impl}}::some_method` where `{{impl}}` somehow identifies
-the the `impl` in question. Since `impl`s don't have names, we'd have to
+the `impl` in question. Since `impl`s don't have names, we'd have to
 use an indexing scheme like the one used for closures (and indeed, this is
 what the compiler does internally). Adding in generic arguments to, this
 would lead to symbol names looking like

text/3308-offset_of.md

@@ -202,7 +202,7 @@ types:
     In this case, `$field` must share a name or tuple index with a field which:
     - Exists on `$Container`.
     - Is visible at the location where `offset_of!` is invoked (but there is no
-      requirement that fields other than than `$field` be visible there)
+      requirement that fields other than `$field` be visible there)
 
 2. An anonymous tuple type.
 

text/3535-constants-in-patterns.md

@@ -245,7 +245,7 @@ Some possible alternatives include:
 - **Reject pointers completely.**
   This was considered, but matching against sentinel values of raw pointers is a pretty common pattern, so we should have a really good reason to break that code---and we do not.
 - **Involve `Eq`.**
-  This RFC is is completely defined in terms of `PartialEq`; the `Eq` trait plays no role.
+  This RFC is completely defined in terms of `PartialEq`; the `Eq` trait plays no role.
   This is primarily because we allow floating-point values in patterns, which means that we cannot require the constant to implement `Eq` in the first place.
 - **Do not require `PartialEq`.**
   Currently we check both that the constant value has recursive structural equality, and that its type implements `PartialEq`.