Merge pull request #3690 from cuishuang/master

fix some comments

Author: fmease

text/0339-statically-sized-literals.md

@@ -115,7 +115,7 @@ The alternative design is to make the literals the values and not the references
 1)
 Keep the types of array literals as `[T, ..N]`.
 Change the types of byte literals from `&'static [u8]` to `[u8, ..N]`.
-Change the types of string literals form `&'static str` to to `FixedString<N>`.
+Change the types of string literals form `&'static str` to `FixedString<N>`.
 2)
 Introduce the missing family of types - strings of fixed size - `FixedString<N>`.
 ...

text/0403-cargo-build-command.md

@@ -184,7 +184,7 @@ are target triples. The dependencies section underneath is the same as the
 top-level dependencies section in terms of functionality.
 
 Semantically, platform specific dependencies are activated whenever Cargo is
-compiling for a the exact target. Dependencies in other `$target` sections
+compiling for the exact target. Dependencies in other `$target` sections
 will not be compiled.
 
 However, when generating a lockfile, Cargo will always download all dependencies

text/1869-eprintln.md

@@ -75,7 +75,7 @@ instead; similarly for `print!`.
 
 The usual drawbacks of adding macros to the prelude apply.  In this
 case, I think the most significant concern is to choose names that are
-unlikely to to conflict with existing library crates' _exported_
+unlikely to conflict with existing library crates' _exported_
 macros.  (Conversely, _internal_ macros with the same names and
 semantics demonstrate that the names chosen are appropriate.)
 

text/1990-external-doc-attribute.md

@@ -182,7 +182,7 @@ provide context as to what's going on and where to find this file for inclusion.
 The acceptance of this proposal would minimally impact all levels of Rust users
 as it is something that provides convenience but is not a necessary thing to
 learn to use Rust. It should be taught to existing users by updating
-documentation to show it in use and to include in in the Rust Programming
+documentation to show it in use and to include in the Rust Programming
 Language book to teach new users. Currently the newest version of The Rust
 Programming Language book has a section for [doc comments](https://doc.rust-lang.org/nightly/book/second-edition/ch14-02-publishing-to-crates-io.html#documentation-comments) that will need to be expanded
 to show how users can include docs from external sources. The Rust Reference

text/2300-self-in-typedefs.md

@@ -638,7 +638,7 @@ impl Trait for Foo {
 ### Conclusion
 
 We've now examined a few cases and seen that indeed, the meaning of `Self` is
-consistent in all of them as well as with what the meaning in in today's Rust.
+consistent in all of them as well as with what the meaning in today's Rust.
 
 ## Doing nothing
 

text/2361-dbg-macro.md

@@ -140,7 +140,7 @@ However a library can always define another macro with the same name and shadow
 # Rationale and alternatives
 [alternatives]: #alternatives
 
-[RFC 2173] and provides an a more complex alternative that offers more control but is also more complex.
+[RFC 2173] and provides a more complex alternative that offers more control but is also more complex.
 This RFC was designed with the goal of being a simpler and thus better fit for the standard library.
 
 ## Alternative: tweaking formatting

text/2451-re-rebalancing-coherence.md

@@ -192,7 +192,7 @@ least one of the following is true:
   - No uncovered type parameters `P1..=Pn` may appear in `T0..Ti` (excluding
     `Ti`)
 
-The primary change from the rules defined in in [RFC #1023] is that we only
+The primary change from the rules defined in [RFC #1023] is that we only
 restrict the appearance of *uncovered* type parameters. Once again, it is
 important to note that for the purposes of coherence, `#[fundamental]` types are
 special. `Box<T>` is not considered covered, and `Box<LocalType>` is considered

text/2867-isa-attribute.md

@@ -28,7 +28,7 @@ fn add_one(x: i32) -> i32 {
     x + 1
 }
 
-// This will compile as `a32` code on both `arm` and thumb` targets
+// This will compile as `a32` code on both `arm` and `thumb` targets
 #[instruction_set(arm::a32)]
 fn add_five(x: i32) -> i32 {
     x + 5

text/3389-manifest-lint.md

@@ -537,7 +537,7 @@ Where `rust-version` is used by cargo to determine whether to pass along this
 lint and `threshold` is used by the tool.  We'd need to define how to
 distinguish between reserved and unreserved field names.
 
-Tool-wide configuration would be in in the `lints.<tool>.metadata` table and be
+Tool-wide configuration would be in the `lints.<tool>.metadata` table and be
 completely ignored by `cargo`.  For example:
 ```toml
 [lints.clippy.metadata]

text/3467-unsafe-pinned.md

@@ -412,7 +412,7 @@ However, of course one could imagine alternatives:
 - `UnsafePinned` could affect aliasing guarantees *both* on mutable and shared references. This would avoid the currently rather subtle situation that arises when one of many aliasing `&mut UnsafePinned<T>` is cast or coerced to `&UnsafePinned<T>`: that is a read-only shared reference and all aliases must stop writing!
   It would make this type strictly more 'powerful' than `UnsafeCell` in the sense that replacing `UnsafeCell` by `UnsafePinned` would always be correct. (Under the RFC as written, `UnsafeCell` and `UnsafePinned` can be nested to remove aliasing requirements from both shared and mutable references.)
 
-  If we don't do this, we could consider removing `get` since since it seems too much like a foot-gun.
+  If we don't do this, we could consider removing `get` since it seems too much like a foot-gun.
   But that makes shared references to `UnsafePinned` fairly pointless. Shared references to generators/futures are basically useless so it is unclear what the potential use-cases here are.
 
 - Instead of introducing a new type, we could say that `UnsafeCell` affects *both* shared and mutable references. That would lose some optimization potential on types like `&mut Cell<T>`, but would avoid the footgun of coercing an `&mut UnsafePinned<T>` to `&UnsafePinned<T>`. That said, so far the author is not aware of Miri detecting code that would run into this footgun (and Miri is [able to detect such issues](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=aab417b535f7dbd266fbfe470ea208c7)).