Fix typos in RFCs 3001-3250

Author: jhpratt

text/3013-conditional-compilation-checking.md

@@ -153,7 +153,7 @@ rustc --check-cfg 'names(is_embedded, has_feathers)' \
 #[cfg(is_embedded)] // this is valid, and #[cfg] evaluates to disabled
 fn do_embedded() {}
 
-#[cfg(has_feathers)] // this is valid, and #[cfg] evalutes to enabled
+#[cfg(has_feathers)] // this is valid, and #[cfg] evaluates to enabled
 fn do_features() {}
 
 #[cfg(has_mumble_frotz)] // this is INVALID
@@ -204,7 +204,7 @@ rustc --check-cfg 'names(is_embedded, has_feathers)' \
 #[cfg(is_embedded)]         // this is valid, and #[cfg] evaluates to disabled
 fn do_embedded() {}
 
-#[cfg(has_feathers)]        // this is valid, and #[cfg] evalutes to enabled
+#[cfg(has_feathers)]        // this is valid, and #[cfg] evaluates to enabled
 fn do_features() {}
 
 #[cfg(has_mumble_frotz)]    // this is INVALID, because has_mumble_frotz is not in the
@@ -588,7 +588,7 @@ But for crates that do have a `build.rs` script, we may need a way for those scr
 control the behavior of checking condition names.
 
 One possible source of problems may come from build scripts (`build.rs` files) that add `--cfg`
-options that Cargo is not aware of. For exaple, if a `Cargo.toml` file did _not_ define a feature
+options that Cargo is not aware of. For example, if a `Cargo.toml` file did _not_ define a feature
 flag of `foo`, but the `build.rs` file added a `--cfg feature="foo"` option, then source code
 could use `foo` in a condition. My guess is that this is rare, and that a Crater run will expose
 this kind of problem.

text/3014-must-not-suspend-lint.md

@@ -135,7 +135,7 @@ The `#[must_use]` attribute ensures that if a type or the result of a function i
 
 * [Clippy lint for holding locks across await points](https://github.com/rust-lang/rust-clippy/pull/5439)
 * [Must use for functions](https://github.com/iopq/rfcs/blob/f4b68532206f0a3e0664877841b407ab1302c79a/text/1940-must-use-functions.md)
-* Reference link on how mir transfroms async fn https://tmandry.gitlab.io/blog/posts/optimizing-await-2/
+* Reference link on how mir transforms async fn https://tmandry.gitlab.io/blog/posts/optimizing-await-2/
 # Unresolved questions
 [unresolved-questions]: #unresolved-questions
 

text/3028-cargo-binary-dependencies.md

@@ -88,7 +88,7 @@ Artifact dependencies can appear in any of the three sections of dependencies (o
 - `[dependencies]`
 - `[dev-dependencies]`
 
-By default, `build-dependencies` are built for the host, while  `dependencies` and `dev-dependencies` are built for the target. You can specify the `target` attribute to build for a specific target, such as `target = "wasm32-wasi"`; a literal `target = "target"` will build for the target even if specifing a build dependency. (If the target is not available, this will result in an error at build time, just as if building the specified crate with a `--target` option for an unavailable target.)
+By default, `build-dependencies` are built for the host, while  `dependencies` and `dev-dependencies` are built for the target. You can specify the `target` attribute to build for a specific target, such as `target = "wasm32-wasi"`; a literal `target = "target"` will build for the target even if specifying a build dependency. (If the target is not available, this will result in an error at build time, just as if building the specified crate with a `--target` option for an unavailable target.)
 
 Cargo provides the following environment variables to the crate being built:
 
@@ -109,7 +109,7 @@ Similar to features, if other crates in your dependencies also depend on the sam
 
 Cargo will unify versions across all kinds of dependencies, including artifact dependencies, just as it does for multiple dependencies on the same crate throughout a dependency tree.
 
-Cargo will not unify features across dependencies for different targets. One dependency tree may have both ordinary dependencies and artifact dependencies on the same crate, with different features for the ordinary dependency and for artifact depenencies for different targets.
+Cargo will not unify features across dependencies for different targets. One dependency tree may have both ordinary dependencies and artifact dependencies on the same crate, with different features for the ordinary dependency and for artifact dependencies for different targets.
 
 `artifact` may be a string, or a list of strings; in the latter case, this specifies a dependency on the crate with each of those artifact types, and is equivalent to specifying multiple dependencies with different `artifact` values. For instance, you may specify a build dependency on both a binary and a cdylib from the same crate. You may also specify separate dependencies with different `artifact` values, as well as dependencies on the same crate without `artifact` specified; for instance, you may have a build dependency on the binary of a crate and a normal dependency on the Rust library of the same crate.
 

text/3086-macro-metavar-expr.md

@@ -41,7 +41,7 @@ the *number* of repetitions of `$x`.
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
-The [example `vec` macro defininition in the guide][guide-vec] could be made
+The [example `vec` macro definition in the guide][guide-vec] could be made
 more efficient if it could use `Vec::with_capacity` to pre-allocate a vector
 with the correct capacity.  To do this, we need to know the number of
 repetitions.
@@ -277,7 +277,7 @@ these workarounds are sometimes difficult to discover and naive
 implementations can significantly harm compiler performance.
 
 Furthermore, the additional syntax is limited to declarative macros, and its
-use should be limited to specific circustances where it is more understandable
+use should be limited to specific circumstances where it is more understandable
 than the alternatives.
 
 # Rationale and alternatives

text/3101-reserved_prefixes.md

@@ -104,7 +104,7 @@ There is one subtle note to this reservation: because raw string literals and st
 # Guide-level explanation
 When designing DSLs via macros that take token trees as inputs, be aware that certain syntactic productions which have no meaning in Rust are nonetheless forbidden by the grammar, as they represent "reserved space" for future language development. In particular, anything of the form `<identifier>#<identifier>`, `<identifier>"<string contents>"`, `<identifier>'<char contents>'`, and `<identifier>#<numeric literal>` is reserved for exclusive use by the language; these are called *reserved prefixes*.
 
-Unless a prefix has been assigned a specific meaning by the language (e.g. `r#async`, `b"foo"`), Rust will fail to tokenize when encountering any code that attempts to make use of such prefixes. Note that these prefixes rely on the absence of whitespace, so a macro invocation can use `<identifier> # <identifer>` (note the spaces) as a way to consume individual tokens adjacent to a `#`.
+Unless a prefix has been assigned a specific meaning by the language (e.g. `r#async`, `b"foo"`), Rust will fail to tokenize when encountering any code that attempts to make use of such prefixes. Note that these prefixes rely on the absence of whitespace, so a macro invocation can use `<identifier> # <identifier>` (note the spaces) as a way to consume individual tokens adjacent to a `#`.
 
 Putting it all together, this means that the following are valid macro invocations:
 

text/3119-rust-crate-ownership.md

@@ -118,7 +118,7 @@ Any transition _away_ from "Intentional Artifact" requires an RFC.
 
 Any transition to "Intentional Artifact" should ideally be accompanied by an RFC, and an update to the team charter if there is one.
 
-Expatriation should basically _never_ occur anymore, but it also requires an RFC and core team approval in case it is really necessary. If a team wishes to stop working on a crate, they should deprecate it and encourage the community to fork it or build their own thing. The repository may be transfered out, however the `crates.io` name is kept by the Rust project and the new group of maintainers will need to pick a new crate name.
+Expatriation should basically _never_ occur anymore, but it also requires an RFC and core team approval in case it is really necessary. If a team wishes to stop working on a crate, they should deprecate it and encourage the community to fork it or build their own thing. The repository may be transferred out, however the `crates.io` name is kept by the Rust project and the new group of maintainers will need to pick a new crate name.
 
 If "transitively intentional" crates are being deprecated care should be taken to ensure security issues will still be handled.
 

text/3176-cargo-multi-dep-artifacts.md

@@ -104,7 +104,7 @@ textually identical, as long as they resolve to the same version.
 Cargo will not unify features across dependencies for different targets. One
 dependency tree may have both ordinary dependencies and multiple artifact
 dependencies on the same crate, with different features for the ordinary
-dependency and for artifact depenencies for different targets.
+dependency and for artifact dependencies for different targets.
 
 Building an artifact dependency for multiple targets may entail building
 multiple copies of other dependencies, which must similarly unify within a

text/3191-debugger-visualizer.md

@@ -277,7 +277,7 @@ This section describes how GDB's pretty printers are supported in Rust.
 To use a pretty printer, developers write python scripts that describe how a type
 should be displayed when loaded up in GDB/LLDB. (See: https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing.html#Pretty-Printing)
 The pretty printers provide patterns, which match type names, and for matching
-types, descibe how to display those types. (For writing a pretty printer, see: https://sourceware.org/gdb/onlinedocs/gdb/Writing-a-Pretty_002dPrinter.html#Writing-a-Pretty_002dPrinter).
+types, describe how to display those types. (For writing a pretty printer, see: https://sourceware.org/gdb/onlinedocs/gdb/Writing-a-Pretty_002dPrinter.html#Writing-a-Pretty_002dPrinter).
 
 Rust developers can add one or more pretty printers to their crate. This is done
 in the Rust compiler via python scripts. Through the use of the new Rust attribute

text/3231-cargo-asymmetric-tokens.md

@@ -137,7 +137,7 @@ Credential Processes as defined in [RFC 2730](https://github.com/rust-lang/rfcs/
 Some credential processes that might be useful for people to develop include:
 - The ability to store keys in operating systems specific secure enclaves.
 - the ability to use keys embedded in common hardware tokens.
-- The ability to read keys in formats used by other tools (GPG, SSH, PKCS#12, ect.)
+- The ability to read keys in formats used by other tools (GPG, SSH, PKCS#12, etc.)
 
 ## Note on stability