Merge pull request #3598 from JohnEndson/master

chore: fix some comments

text/0461-tls-overhaul.md

@@ -215,7 +215,7 @@ have `with` `panic!` instead.
 ## Owning TLS
 
 Although scoped TLS can store any value, it is also limited in the fact that it
-cannot own a value. This means that TLS values cannot escape the stack from from
+cannot own a value. This means that TLS values cannot escape the stack from
 which they originated from. This is itself another common usage pattern of TLS,
 and to solve this problem the `std::tls` module will provided support for
 placing owned values into TLS.

text/0494-c_str-and-c_vec-stability.md

@@ -179,7 +179,7 @@ and `with_c_str` methods are no longer in the prelude by default, and
   directly calling `CString::from_vec`, but it may be more frequently called via
   `CString::from_slice`, resulting in an unnecessary allocation. Note, however,
   that one would have to remember to call `into_c_str` on the `ToCStr` trait, so
-  it doesn't necessarily help too too much.
+  it doesn't necessarily help too much.
 
 * The ergonomics of operating C strings have been somewhat reduced as part of
   this design. The `CString::from_slice` method is somewhat long to call

text/1044-io-fs-2.1.md

@@ -372,7 +372,7 @@ future, such as [C++'s template parameter][cpp-dir-template]:
 pub fn template<P: AsRef<Path>>(&mut self, path: P) -> &mut Self;
 ```
 
-At this time, however, it it not proposed to add this method to
+At this time, however, it is not proposed to add this method to
 `DirBuilder`.
 
 ## Adding `FileType`

text/1414-rvalue_static_promotion.md

@@ -118,7 +118,7 @@ let x: &'static T = &<constexpr foo>;
 The necessary changes in the compiler did already get implemented as
 part of codegen optimizations (emitting references-to or memcopies-from values in static memory instead of embedding them in the code).
 
-All that is left do do is "throw the switch" for the new lifetime semantic
+All that is left to do is "throw the switch" for the new lifetime semantic
 by removing these lines:
 https://github.com/rust-lang/rust/blob/29ea4eef9fa6e36f40bc1f31eb1e56bf5941ee72/src/librustc/middle/mem_categorization.rs#L801-L807
 

text/2044-license-rfcs.md

@@ -85,7 +85,7 @@ Also, after this RFC got merged, all RFCs in the queue will get a comment in
 their Github PR and be asked to include the copyright section at the top of
 their RFC file.
 
-The note in README.md should should inform new PR authors of the terms
+The note in README.md should inform new PR authors of the terms
 they put their contribution under.
 
 # Drawbacks

text/3509-prelude-2024-future.md

@@ -55,7 +55,7 @@ mod rust_2024 {
 # Tradeoffs
 [tradeoffs]: #tradeoffs
 
-Both the `Future` and `IntoFuture` definitions in the standard library are considered _canonical_: there exist no widespread alternative definitions in the Rust ecosystem. Simply having both traits in scope is unlikely to lead to any issues, and the only likely noticable outcome is that authoring async code will require slightly less effort.
+Both the `Future` and `IntoFuture` definitions in the standard library are considered _canonical_: there exist no widespread alternative definitions in the Rust ecosystem. Simply having both traits in scope is unlikely to lead to any issues, and the only likely noticeable outcome is that authoring async code will require slightly less effort.
 
 # Rationale and alternatives
 [rationale-and-alternatives]: #rationale-and-alternatives
@@ -68,7 +68,7 @@ However, it's possible to use different criteria for what should be included in
 
 Both of these perspectives can be applied to other scenarios too. Let's say we're finally able to stabilize the `Try` trait; should this be included in the following prelude? From a systems-based perspective, the answer would be "yes", since it's a fundamental operation which enables types to be named. From the merit-based perspective the answer would likely be "no", since it will be a new trait with limited usage. But it might be re-considered once it sees enough usage.
 
-We believe that taking a merit-based perspective makes sense if the upsides of a choice also carry noteable downsides. But as covered in the "tradeoffs" section of this RFC, there don't appear to be any meaningful downsides. So instead it seems better to base our evalutation on how the traits relate to the language, rather than on how much usage they see.
+We believe that taking a merit-based perspective makes sense if the upsides of a choice also carry notable downsides. But as covered in the "tradeoffs" section of this RFC, there don't appear to be any meaningful downsides. So instead it seems better to base our evaluation on how the traits relate to the language, rather than on how much usage they see.
 
 # Prior art
 [prior-art]: #prior-art
@@ -81,7 +81,7 @@ The Rust 2021 edition includes three new traits:
 - `TryFrom` - fallible conversion
 - `TryInto` - fallible conversion (inverted)
 
-All three of these traits represent fundamental operations present in Rust. This is a natural supplement to other fundamental operations present in earlier editions such as `Try`, `Into`, and `IntoIterator`. I'd argue that `Future` and `IntoFuture` have an an equal, if not more fundamental relationship to the Rust language than `TryFrom` or `FromIterator` do.
+All three of these traits represent fundamental operations present in Rust. This is a natural supplement to other fundamental operations present in earlier editions such as `Try`, `Into`, and `IntoIterator`. I'd argue that `Future` and `IntoFuture` have an equal, if not more fundamental relationship to the Rust language than `TryFrom` or `FromIterator` do.
 
 # Unresolved questions
 [unresolved-questions]: #unresolved-questions

text/3543-patchable-function-entry.md

@@ -203,7 +203,7 @@ Possible actions we could take include:
 
 Since we don't have a way to "reset" inlining to default, any plan involving suppression of inlining also needs to come with additional configuration to suppress the suppression.
 
-### Inline suppresssion
+### Inline suppression
 If the function has nonzero `entry` padding, prevent inlining.
 
 Add `-C allow-patchable-function-inlining` to disable this behavior.
@@ -214,7 +214,7 @@ The advantage of this approach is that any instrumentation will always trigger w
 
 Disadvantages:
 
-- When the flag is passed, we will disable inlining *nearly everywhere*. This would be disasterous for performance, given the number of functions Rust depends on inlining to optimize.
+- When the flag is passed, we will disable inlining *nearly everywhere*. This would be disastrous for performance, given the number of functions Rust depends on inlining to optimize.
 - This does not match C/C++ behavior, which means most existing use cases will be surprised.
 - We need to add flag complexity to match existing use cases.