From cdf8dd5948dac514ae466122c64cdbb8b5b322c2 Mon Sep 17 00:00:00 2001 From: toofooboo Date: Fri, 19 Apr 2024 19:37:30 +0800 Subject: [PATCH] text: fix typos in comments Signed-off-by: toofooboo --- text/0235-collections-conventions.md | 2 +- text/0517-io-os-reform.md | 2 +- text/1636-document_all_features.md | 2 +- text/2103-tool-attributes.md | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0235-collections-conventions.md b/text/0235-collections-conventions.md index 8a44b60c..cf652fbf 100644 --- a/text/0235-collections-conventions.md +++ b/text/0235-collections-conventions.md @@ -1108,7 +1108,7 @@ These traits will be implemented for: `[T]`, `Vec`, `RingBuf`, `HashMap`, `TreeM As a general convention, implementation of the `Index` traits will *fail the task* if the index is invalid (out of bounds or key not found); they will -therefor return direct references to values. Any collection implementing `Index` +therefore return direct references to values. Any collection implementing `Index` (resp. `IndexMut`) should also provide a `get` method (resp. `get_mut`) as a non-failing variant that returns an `Option` value. diff --git a/text/0517-io-os-reform.md b/text/0517-io-os-reform.md index 232103be..a3411b2e 100644 --- a/text/0517-io-os-reform.md +++ b/text/0517-io-os-reform.md @@ -294,7 +294,7 @@ models or nonblocking IO, nor is it a goal for the blocking APIs to eventually be used in a nonblocking "mode" or style. Rather, the hope is that the basic abstractions of files, paths, sockets, and so -on will eventually be usable directly within an async IO programing model and/or +on will eventually be usable directly within an async IO programming model and/or with nonblocking APIs. This is the case for most existing languages, which offer multiple interoperating IO models. diff --git a/text/1636-document_all_features.md b/text/1636-document_all_features.md index 86963b77..f991d6ca 100644 --- a/text/1636-document_all_features.md +++ b/text/1636-document_all_features.md @@ -115,7 +115,7 @@ Here is the Ember RFC section, with appropriate substitutions and modifications: > # How We Teach This > What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing Rust patterns, or as a wholly new one? > -> Would the acceptance of this proposal change how Rust is taught to new users at any level? What additions or changes to the Rust Reference, _The Rust Programing Language_, and/or _Rust by Example_ does it entail? +> Would the acceptance of this proposal change how Rust is taught to new users at any level? What additions or changes to the Rust Reference, _The Rust Programming Language_, and/or _Rust by Example_ does it entail? > > How should this feature be introduced and taught to existing Rust users? diff --git a/text/2103-tool-attributes.md b/text/2103-tool-attributes.md index 7d646ebb..8ad98bd6 100644 --- a/text/2103-tool-attributes.md +++ b/text/2103-tool-attributes.md @@ -132,7 +132,7 @@ There will be some opt-in mechanism for crates to declare that they want to allow use of a tool's attributes. This might be in the source text (an attribute as in #1755 or new syntax, e.g., `extern attribute foo;`) or passed to rustc as a command line flag (e.g., `--extern-attr foo`). The exact mechanism is -deliberately unspecifed. +deliberately unspecified. After opting-in to `foo`, a crate can use `foo` as the base of a path in any attribute in the crate. E.g., allowing `#[foo::bar]` to be used (but not