From 4417196151ac8c8f0aedac97ab81d522836f5f71 Mon Sep 17 00:00:00 2001 From: JohnEndson Date: Thu, 28 Mar 2024 19:54:49 +0800 Subject: [PATCH] chore: fix some comments Signed-off-by: JohnEndson --- text/0461-tls-overhaul.md | 2 +- text/0494-c_str-and-c_vec-stability.md | 2 +- text/1044-io-fs-2.1.md | 2 +- text/1414-rvalue_static_promotion.md | 2 +- text/2044-license-rfcs.md | 2 +- text/3509-prelude-2024-future.md | 6 +++--- text/3543-patchable-function-entry.md | 4 ++-- 7 files changed, 10 insertions(+), 10 deletions(-) diff --git a/text/0461-tls-overhaul.md b/text/0461-tls-overhaul.md index a5119841..a5c10cd9 100644 --- a/text/0461-tls-overhaul.md +++ b/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. diff --git a/text/0494-c_str-and-c_vec-stability.md b/text/0494-c_str-and-c_vec-stability.md index 40f5cd29..7d076e3e 100644 --- a/text/0494-c_str-and-c_vec-stability.md +++ b/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 diff --git a/text/1044-io-fs-2.1.md b/text/1044-io-fs-2.1.md index 17a1eea9..efa9cefd 100644 --- a/text/1044-io-fs-2.1.md +++ b/text/1044-io-fs-2.1.md @@ -372,7 +372,7 @@ future, such as [C++'s template parameter][cpp-dir-template]: pub fn template>(&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` diff --git a/text/1414-rvalue_static_promotion.md b/text/1414-rvalue_static_promotion.md index 74c2957d..108e0689 100644 --- a/text/1414-rvalue_static_promotion.md +++ b/text/1414-rvalue_static_promotion.md @@ -118,7 +118,7 @@ let x: &'static T = &; 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 diff --git a/text/2044-license-rfcs.md b/text/2044-license-rfcs.md index fbc90746..fdcadac2 100644 --- a/text/2044-license-rfcs.md +++ b/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 diff --git a/text/3509-prelude-2024-future.md b/text/3509-prelude-2024-future.md index 8aa308f9..1c36fefd 100644 --- a/text/3509-prelude-2024-future.md +++ b/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 diff --git a/text/3543-patchable-function-entry.md b/text/3543-patchable-function-entry.md index d468457c..cd1e37f0 100644 --- a/text/3543-patchable-function-entry.md +++ b/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.