chore: fix some comments

Signed-off-by: JohnEndson <jiayuzhen@outlook.com>
This commit is contained in:
JohnEndson 2024-03-28 19:54:49 +08:00
parent 02f38df718
commit 4417196151
7 changed files with 10 additions and 10 deletions

View File

@ -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.

View File

@ -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

View File

@ -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`

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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.