Fix typos in RFCs 2751-3000

text/2789-sparse-index.md

@@ -51,7 +51,7 @@ If the client is not interested in the deleted crate, it won't check it, but cha
 # Drawbacks
 [drawbacks]: #drawbacks
 
-* crates-io plans to add a cryptographic signatures to the index as an extra layer of protection on top of HTTPS. Cryptographic verification of a git index is straigthforward, but signing of a sparse HTTP index may be challenging.
+* crates-io plans to add a cryptographic signatures to the index as an extra layer of protection on top of HTTPS. Cryptographic verification of a git index is straightforward, but signing of a sparse HTTP index may be challenging.
 * A basic solution, without the incremental changelog, needs many requests update the index. This could have higher latency than a git fetch. However, in preliminary benchmarks it appears to be faster than a git fetch if the CDN supports enough (>60) requests in parallel. For GitHub-hosted indexes Cargo has a fast path that checks in GitHub API whether the master branch has changed. With the incremental changelog file, the same fast path can be implemented by making a conditional HTTP request for the changelog file (i.e. checking `ETag` or `Last-Modified`).
 * Performant implementation of this solution depends on making many small requests in parallel. HTTP/2 support on the server makes checking twice as fast compared to HTTP/1.1, but speed over HTTP/1.1 is still reasonable.
 * `raw.githubusercontent.com` is not suitable as a CDN. The sparse index will have to be cached/hosted elsewhere.
@@ -120,4 +120,4 @@ The index does not require all files to form one cohesive snapshot. The index is
 
 The only case where stale caches can cause a problem is when a new version of a crate depends on the latest version of a newly-published dependency, and caches expired for the parent crate before expiring for the dependency. Cargo requires dependencies with sufficient versions to be already visible in the index, and won't publish a "broken" crate.
 
-However, there's always a possiblity that CDN caches will be stale or expire in a "wrong" order. If Cargo detects that its cached copy of the index is stale (i.e. it finds that a crate that depends on a dependency that doesn't appear to be in the index yet) it may recover from such situation by re-requesting files from the index with a "cache buster" (e.g. current timestamp) appended to their URL. This has an effect of reliably bypassing stale caches, even when CDNs don't honor `cache-control: no-cache` in requests.
+However, there's always a possibility that CDN caches will be stale or expire in a "wrong" order. If Cargo detects that its cached copy of the index is stale (i.e. it finds that a crate that depends on a dependency that doesn't appear to be in the index yet) it may recover from such situation by re-requesting files from the index with a "cache buster" (e.g. current timestamp) appended to their URL. This has an effect of reliably bypassing stale caches, even when CDNs don't honor `cache-control: no-cache` in requests.

text/2795-format-args-implicit-identifiers.md

@@ -80,7 +80,7 @@ Implicit arguments would have lower precedence than the existing named arguments
     // expands to "hello Snoopy".
     println!("hello {person}", person="Snoopy");
 
-Indeed, in this example above the `person` variable would be unused, and so in this case the unused varible warning will apply, like the below:
+Indeed, in this example above the `person` variable would be unused, and so in this case the unused variable warning will apply, like the below:
 
     warning: unused variable: `person`
      --> src/foo.rs:X:Y
@@ -116,7 +116,7 @@ The implementation pathway is directly motivated by the guide level explanation
 
    If this RFC were implemented, instead of this resulting in an error, this named argument would be treated as an **implicit named argument** and the final result of the expansion of the `format_args!` macro would be the same as if a named argument, with name equivalent to the identifier, had been provided to the macro invocation.
 
-   Because `person` is only treated as an implicit named argument if no exisiting named argument can be found, this ensures that implicit named arguments have lower precedence than explicit named arguments.
+   Because `person` is only treated as an implicit named argument if no existing named argument can be found, this ensures that implicit named arguments have lower precedence than explicit named arguments.
 
 ## Macro Hygiene
 [macro-hygiene]: #macro-hygiene
@@ -274,7 +274,7 @@ Indeed the RFC's perverse example reads slightly easier with this syntax:
 
     println!("hello {( if self.foo { &self.person } else { &self.other_person } )}");
 
-Because the interpolation syntax `{(expr)}` is orthogonal to positional `{}` and named `{ident}` argument syntax, and is a superset of the functionality which would be offered by implict named arguments, the argument was made that we should make the leap directly to interpolation without introducing implicit named arguments so as to avoid complicating the existing cases.
+Because the interpolation syntax `{(expr)}` is orthogonal to positional `{}` and named `{ident}` argument syntax, and is a superset of the functionality which would be offered by implicit named arguments, the argument was made that we should make the leap directly to interpolation without introducing implicit named arguments so as to avoid complicating the existing cases.
 
 ### Argument Against Interpolation
 
@@ -312,7 +312,7 @@ Similar to how implicit named arguments can be offered by third-party crates, in
 
 The overall argument is not to deny that the standard library macros in question would not become more expressive if they were to gain fully interpolation.
 
-However, the RFC author argues that adding interpolation to these macros is less neccessary to improve ergonomics when comparing against other languages which chose to introduce language-level interpolation support. Introduction of implicit named arguments will cater for many of the common instances where interpolation would have been desired. The existing positional and named arguments can accept arbitrary expressions, and are not so unergonomic that they feel overly cumbersome when the expression in question is also nontrivial.
+However, the RFC author argues that adding interpolation to these macros is less necessary to improve ergonomics when comparing against other languages which chose to introduce language-level interpolation support. Introduction of implicit named arguments will cater for many of the common instances where interpolation would have been desired. The existing positional and named arguments can accept arbitrary expressions, and are not so unergonomic that they feel overly cumbersome when the expression in question is also nontrivial.
 
 
 # Prior art
@@ -332,7 +332,7 @@ This syntax is widely used and clear to read. It's [introduced in the Rust Book
 
 ## Other languages
 
-A number of languages support string-interpolation functionality with similar syntax to what Rust's formatting macros. The RFC author's influence comes primarily from Python 3's "f-strings" and Javscript's backticks.
+A number of languages support string-interpolation functionality with similar syntax to what Rust's formatting macros. The RFC author's influence comes primarily from Python 3's "f-strings" and JavaScript's backticks.
 
 The following code would be the equivalent way to produce a new string combining a `greeting` and a `person` in a variety of languages:
 
@@ -363,7 +363,7 @@ The following code would be the equivalent way to produce a new string combining
 
 It is the RFC author's experience that these interpolating mechanisms read easily from left-to-right and it is clear where each variable is being substituted into the format string.
 
-In the Rust formatting macros as illustrated above, the positional form suffers the drawback of not reading strictly from left to right; the reader of the code must refer back-and-forth between the format string and the argument list to determine where each variable will be subsituted. The named form avoids this drawback at the cost of much longer code.
+In the Rust formatting macros as illustrated above, the positional form suffers the drawback of not reading strictly from left to right; the reader of the code must refer back-and-forth between the format string and the argument list to determine where each variable will be substituted. The named form avoids this drawback at the cost of much longer code.
 
 Implementing implicit named arguments in the fashion suggested in this RFC would eliminate the drawbacks of each of the Rust forms and permit new syntax much closer to the other languages:
 
@@ -396,7 +396,7 @@ However, in current stable Rust the `panic!` macro does not forward to `format_a
 
 This semantic of `panic!` has previously been acknowledged as a "papercut", for example in [this Rust issue](https://github.com/rust-lang/rust/issues/22932). However, it has so far been left as-is because changing the design was low priority, and changing it may break existing code.
 
-If this RFC were to be implemented, users will very likely expect invoking `panic!` with only a string literal will capture any implicit named arguments. This semantic would quickly become percieved as a major bug rather than a papercut.
+If this RFC were to be implemented, users will very likely expect invoking `panic!` with only a string literal will capture any implicit named arguments. This semantic would quickly become perceived as a major bug rather than a papercut.
 
 Implementing this RFC therefore would bring strong motivation for making a small breaking change to `panic!`: when a single argument passed to panic is a string literal, instead of the final panic message being that literal (the current behavior), the final panic message will be the formatted literal, substituting any implicit named arguments denoted in the literal.
 

text/2834-cargo-report-future-incompat.md

@@ -316,7 +316,7 @@ For example, in our running example of `unwary`:
     will invoke `rustc` itself the same way, and each `rustc` invocation will emit
     the same set of diagnostics that it does today for each of those cases.
   * Thus, the warning lints in the downstream `brash` non-path dependency will
-    be capped, and the future-incompatiblity warnings associated with that `rustc`
+    be capped, and the future-incompatibility warnings associated with that `rustc`
     invocation will be hidden.
   * When `cargo` emits a future-incompatibility report at the end of the build,
     and reports that `brash` contains code that will be rejected by
@@ -383,7 +383,7 @@ The responsibilities of Cargo:
     are not mandated by this RFC, but some ideas are presented as
     [Future possibiilties][future-possibilities].
 
-## Implmentation strategy: Leverage JSON error-format
+## Implementation strategy: Leverage JSON error-format
 
 The cleanest way to implement the above division of responsbilities
 without perturbing *non-cargo* uses of `rustc` is probably to make 
@@ -431,7 +431,7 @@ In particular, it may not be reasonable for someone to resolve the
 flagged problem in the short term.
 
 In order to allow users to opt-out of being warned about future
-incompatiblity issues on every build, this RFC proposes
+incompatibility issues on every build, this RFC proposes
 extending the `.cargo/config` file with keys that allow
 the user to fine-tune the frequency of how often cargo will
 print the report. For example:
@@ -526,7 +526,7 @@ takes a lot of effort to make such transitions, (in no small part
 **because** of the issue described here).
 
 In the cases where the compiler and language teams have turned such
-lints into hard errors, the teams spent signficant time evaluating
+lints into hard errors, the teams spent significant time evaluating
 breakage via crater and then addressing such breakage. The changes
 suggested here would hopefully encourage more Rust users *outside* of
 the compiler and language teams to address future-compatibility
@@ -547,7 +547,7 @@ to `rustc` itself, and isolate the implementation to `cargo` alone.
 The main way I can imagine doing this is to stop passing
 `--cap-lints=allow`, and then having Cargo capture all diagnostic
 output from the compiler and post-processing it to determine which
-lints are future-incompatible warnings. However, ths has a number of
+lints are future-incompatible warnings. However, this has a number of
 problems:
 
  * It is fragile, since it relies on Cargo post-processing the compiler diagnostic output.
@@ -678,7 +678,7 @@ The main form of follow-up work I envisage for this RFC is what
 feedback that Cargo gives regarding the issues.
 
 Cargo is responsible for suggesting to the user how they might address an
-instance of a future-incompatbility lint.
+instance of a future-incompatibility lint.
 
 Some ideas for suggestions follow.
 

text/2873-inline-asm.md

@@ -321,7 +321,7 @@ In some cases, fine control is needed over the way a register name is formatted
 
 By default the compiler will always choose the name that refers to the full register size (e.g. `rax` on x86-64, `eax` on x86, etc).
 
-This default can be overriden by using modifiers on the template string operands, just like you would with format strings:
+This default can be overridden by using modifiers on the template string operands, just like you would with format strings:
 
 ```rust
 let mut x: u16 = 0xab;
@@ -860,7 +860,7 @@ There is however a fairly trivial mapping between the GCC-style and this format
 
 Additionally, this RFC proposes using the Intel asm syntax by default on x86 instead of the AT&T syntax. We believe this syntax will be more familiar to most users, but may be surprising for users used to GCC-style asm.
 
-The `cpuid` example above would look like this in GCC-sytle inline assembly:
+The `cpuid` example above would look like this in GCC-style inline assembly:
 
 ```C
 // GCC doesn't allow directly clobbering an input, we need

text/2906-cargo-workspace-deduplicate.md

@@ -440,7 +440,7 @@ continue to prune accidentally unused entries.
 ## Effect on `cargo metadata`
 
 Executing `cargo metadata` to learn about a crate graph will implicitly perform
-all subsitution defined in this proposal. Consumers of `cargo metadata` will
+all substitution defined in this proposal. Consumers of `cargo metadata` will
 continue to get the same output they got before this proposal, meaning that
 implicit substitutions, if any, will be invisible to users of `cargo metadata`.
 
@@ -455,7 +455,7 @@ Like today, `path` dependencies will be resolved relative to the file that
 defines them. This means that references to dependencies defined in the
 workspace means paths are still relative to the workspace root itself.
 
-For example if you write down a `[workspace.depencencies]` directive with a
+For example if you write down a `[workspace.dependencies]` directive with a
 relative path:
 
 ```toml

text/2909-destructuring-assignment.md

@@ -233,7 +233,7 @@ meaning for `@`-bindings in destructuring assignment is not inconceivable, we be
 confusing at best in this context. Conversely, destructuring tuples, slices or structs is very
 natural and we do not foresee confusion with allowing these.
 
-Our implementation is forwards-compatible with allowing these patterns in destructuring assigmnent,
+Our implementation is forwards-compatible with allowing these patterns in destructuring assignment,
 in any case, so we lose nothing by not allowing them from the start.
 
 Additionally, we do not give analogues for any of the following, which make little sense in this

text/2912-rust-analyzer.md

@@ -12,7 +12,7 @@ The RFC proposes a plan to adopt rust-analyzer as Rust's official LSP implementa
 * **Deprecation period** -- announce that the RLS is deprecated and encourage people to migrate to rust-analyzer
 * **Final transition** -- stop supporting the older RLS
 
-As detailed below, one major concern with rust-analyzer as it stands today is that it shares very little code with rustc. To avoid creating an unsustainable maintainance burden, this RFC proposes extracting shared libraries that will be used by both rustc and rust-analyzer ("library-ification"), which should eventually lead to rustc and rust-analyzer being two front-ends over a shared codebase.
+As detailed below, one major concern with rust-analyzer as it stands today is that it shares very little code with rustc. To avoid creating an unsustainable maintenance burden, this RFC proposes extracting shared libraries that will be used by both rustc and rust-analyzer ("library-ification"), which should eventually lead to rustc and rust-analyzer being two front-ends over a shared codebase.
 
 # Motivation
 [motivation]: #motivation
@@ -73,7 +73,7 @@ Library-ification can address these concerns by two distinct "host processes" th
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
-The high-level plan is effectively to adopt rust-analyzer as the primary LSP implementation for the Rust project, and to aggressively pursue 'library-ification' as a means to eliminate code duplication. The ultimate vision is that the majority of the compiler logic should live in shared libaries which have two "front-ends", one from rustc and one from rust-analyzer.
+The high-level plan is effectively to adopt rust-analyzer as the primary LSP implementation for the Rust project, and to aggressively pursue 'library-ification' as a means to eliminate code duplication. The ultimate vision is that the majority of the compiler logic should live in shared libraries which have two "front-ends", one from rustc and one from rust-analyzer.
 
 ## Adopting rust-analyzer as the primary LSP implementation
 
@@ -141,7 +141,7 @@ The primary drawback to the plan is that, in the short term, rust-analyzer and r
 
 A secondary drawback is that rust-analyzer today sometimes uses approximate answers where the current RLS is able to offer precise results. This can occur, for example, with jump to definition. This situation will continue to be the case until we make progress on library-ification of parsing and name resolution. 
 
-More generally, switching the offical IDE from RLS to rust-analyzer will incure tooling churn on users, and would not be strictly better in the short term (althought the expectation is that it will be significantly better on average).
+More generally, switching the official IDE from RLS to rust-analyzer will incur tooling churn on users, and would not be strictly better in the short term (although the expectation is that it will be significantly better on average).
 
 # Rationale and alternatives
 [rationale-and-alternatives]: #rationale-and-alternatives
@@ -173,10 +173,10 @@ The reasons behind these limitations are that it will take some time to implemen
 
 The current proposal is informed by experience with existing RLS and query-based compilation in rustc. Additionally, rust-analyzer heavily draws from lessons learned while developing IntelliJ Rust.
 
-It's interesting that many compilers went through a phase with parallel implementaitons to get a great IDE support
+It's interesting that many compilers went through a phase with parallel implementations to get a great IDE support
 
-* For C#, the [Roslyn](https://github.com/dotnet/roslyn) project was a from scratch implemenation.
-* [Dart for a long time had different front-ends for command line and interractive compilers](https://youtu.be/WjdrUphF5l4?t=2204)
+* For C#, the [Roslyn](https://github.com/dotnet/roslyn) project was a from scratch implementation.
+* [Dart for a long time had different front-ends for command line and interactive compilers](https://youtu.be/WjdrUphF5l4?t=2204)
 * [Swift is transitioning to new syntax tree library by "reimplement separately, then swap" approach](https://medium.com/@kitasuke/deep-dive-into-integrating-libsyntax-into-the-compiler-pipeline-2d478c8600a1)
 
 Notable exceptions:

text/2945-c-unwind-abi.md

@@ -71,7 +71,7 @@ how well the current design satisfies these constraints.
 * **Enable foreign exceptions to propagate through Rust frames:**
   Similarly, we would like to make it possible for C++ code (or other
   languages) to raise exceptions that will propagate through Rust
-  frames "as if" they were Rust panics (i.e., running destrutors or,
+  frames "as if" they were Rust panics (i.e., running destructors or,
   in the case of `unwind=abort`, aborting the program).
 * **Enable error handling with `longjmp`:**
   As mentioned above, some existing Rust libraries rely on the ability to
@@ -437,7 +437,7 @@ The attribute approach was deemed insufficient for the following reasons:
   change in the future, but until then, attributes cannot provide any way to
   differentiate function pointers that may unwind from those that are
   guaranteed not to. Assuming that no function pointers may unwind is not
-  viable, because that severly limits the utility of cross-FFI unwinding.
+  viable, because that severely limits the utility of cross-FFI unwinding.
   Conversely, assuming that all `extern "C"` function pointers may unwind is
   inconsistent with the no-unwind default for `extern "C"` functions.
 * The existence of a compatible unwind mechanism on both sides of a function
@@ -514,7 +514,7 @@ language or standard library feature.
 
 Coercions between `"C-unwind"` function types (such as function pointers) and
 the other ABIs are not part of this RFC. However, they will probably be
-indispensible for API design, so we plan to provide them in a future RFC.
+indispensable for API design, so we plan to provide them in a future RFC.
 
 As mentioned [above][rationale], shims will be required if Rust changes its
 unwind mechanism.

text/2959-promote-aarch64-unknown-linux-gnu-to-tier1.md

@@ -107,7 +107,7 @@ As mentioned in the [summary](#Summary), items in 3 above are **required next st
 
  - The evidence to that effect is too numerous to quote but generally easy to verify openly. 
 
- - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the forseeable future.
+ - It is fair to state that this is an ongoing reality which is unlikely to stop trending upwards and sidewards for the foreseeable future.
 
  - Software stacks built for those domains predominantly use an AArch64 Linux kernel build.
 
@@ -141,7 +141,7 @@ As mentioned in the [summary](#Summary), items in 3 above are **required next st
 
  - It is hard to concretely quantify this aspect.
 
- - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publically known examples are Microsoft, Google and Amazon. There are many more.
+ - Most major Arm software ecosystem partners are either already using Rust extensively, or are building up to extensive use. A few publicly known examples are Microsoft, Google and Amazon. There are many more.
 
  - Arm itself recognises Rust as an important component to consider in a broader horizontal safety and security foundation across multiple processor portfolios. 
 

text/2963-rustdoc-json.md

@@ -760,7 +760,7 @@ Name       | Type     | Description
 
 Name       | Type     | Description
 -----------|----------|----------------------------------------------------------------------------
-`lifetime` | String   | (*Optional*) The name of the lifetime parameter on this referece, if any.
+`lifetime` | String   | (*Optional*) The name of the lifetime parameter on this reference, if any.
 `mutable`  | bool     | Whether this is a `&mut` or just a `&`.
 `type`     | [Type](#Type) | The Type that this reference references.
 
@@ -1073,15 +1073,15 @@ representation separate from the human-readable outputs:
 - [PureScript] uses an intermediate JSON representation when publishing package information to their
   [Pursuit] directory. It's primarily used to generate documentation, but can also be used to
   generate `etags` files.
-- [DartDoc] is in the process of implementing a JSON ouput.
+- [DartDoc] is in the process of implementing a JSON output.
 - [Doxygen] has an option to generate an XML file with the code's information.
 - [Haskell]'s documentation tool, [Haddock], can generate an intermediate representation used by the
   type search engine [Hoogle] to integrate documentation of several packages.
 - [Kythe] is a "(mostly) language-agnostic" system for integrating documentation across several
-  langauges. It features its own schema that code information can be translated into, that services
+  languages. It features its own schema that code information can be translated into, that services
   can use to aggregate information about projects that span multiple languages.
 - [GObject Introspection] has an intermediate XML representation called GIR that's used to create
-  langauge bindings for GObject-based C libraries. While (at the time of this writing) it's not
+  language bindings for GObject-based C libraries. While (at the time of this writing) it's not
   currently used to create documentation, it is a stated goal to use this information to document
   these libraries.
 

text/2965-project-error-handling.md

@@ -30,7 +30,7 @@ The error handling project group aims to reduce confusion on how to structure er
 
 ### Come to a consensus on current best practices
 
-Here is a tenative starting point, subject to change:
+Here is a tentative starting point, subject to change:
 
 - Use `Result` and `Error` types for recoverable errors.
 - Use `panic` for unrecoverable errors.