Fix typos in RFCs 2751-3000

Author: jhpratt

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: