Fix typos in RFCs 1001-1250

jhpratt · jhpratt · commit b24c899f75b3 · 2022-10-08T01:44:42.000-04:00
diff --git a/text/1014-stdout-existential-crisis.md b/text/1014-stdout-existential-crisis.md
@@ -24,7 +24,7 @@ Update the methods `std::io::stdin` `std::io::stdout` and `std::io::stderr` as f
 
 # Drawbacks
 
-* Hides an error from the user which we may want to expose and may lead to people missing panicks occuring in threads.
+* Hides an error from the user which we may want to expose and may lead to people missing panicks occurring in threads.
 * Some languages, such as Ruby and Python, do throw an exception when stdout is missing.
 
 # Alternatives
diff --git a/text/1023-rebalancing-coherence.md b/text/1023-rebalancing-coherence.md
@@ -184,7 +184,7 @@ operator, it seems reasonable to say that implementing a `Fn` trait is
 itself a breaking change. (This is not to suggest that there is
 something *fundamental* about the `Fn` traits that distinguish them
 from all other traits; just that if the goal is to have rules that
-users can easily remember, saying that implememting a core operator
+users can easily remember, saying that implementing a core operator
 trait is a breaking change may be a reasonable rule, and it enables
 useful patterns to boot -- patterns that are baked into the libstd
 APIs.)
diff --git a/text/1048-rename-soft-link-to-symlink.md b/text/1048-rename-soft-link-to-symlink.md
@@ -143,7 +143,7 @@ Unix.  It is a classic compromise, that makes everyone unhappy.
 
 `sym_link` is slightly more consistent with the complementary `hard_link`
 function, and treating "sym link" as two separate words has some precedent in
-two of the Windows-targetted APIs, Delphi and some of the PowerShell cmdlets
+two of the Windows-targeted APIs, Delphi and some of the PowerShell cmdlets
 observed.  However, I have not found any other snake case API that uses that,
 and only a couple of Windows-specific APIs that use it in camel case; most
 usage prefers the single word "symlink" to the two word "sym link" as the
diff --git a/text/1122-language-semver.md b/text/1122-language-semver.md
@@ -129,7 +129,7 @@ are generally considered underspecified.
 We expect that there will be cases that fall on a grey line between
 bug and expected behavior, and discussion will be needed to determine
 where it falls. The recent conflict between `Rc` and scoped threads is
-an example of such a discusison: it was clear that both APIs could not
+an example of such a discussion: it was clear that both APIs could not
 be legal, but not clear which one was at fault. The results of these
 discussions will feed into the Rust spec as it is developed.
     
@@ -183,7 +183,7 @@ Known areas where change is expected include the following:
   - We plan to stop zeroing data and instead use marker flags on the stack,
     as specified in [RFC 320]. This may affect destructors that rely on ovewriting
     memory or using the `unsafe_no_drop_flag` attribute.
-  - Currently, panicing in a destructor can cause unintentional memory
+  - Currently, panicking in a destructor can cause unintentional memory
     leaks and other poor behavior (see [#14875], [#16135]). We are
     likely to make panic in a destructor simply abort, but the precise
     mechanism is not yet decided.
@@ -281,7 +281,7 @@ the change still breaks a large body of code we do not have access to.
 
 **What attribute should we use to "opt out" of soundness changes?**
 The section on breaking changes indicated that it may sometimes be
-appropriate to includ an "opt out" that people can use to temporarily
+appropriate to include an "opt out" that people can use to temporarily
 revert to older, unsound type rules, but did not specify precisely
 what that opt-out should look like. Ideally, we would identify a
 specific attribute in advance that will be used for such purposes.  In
diff --git a/text/1131-likely-intrinsic.md b/text/1131-likely-intrinsic.md
@@ -5,13 +5,13 @@
 
 # Summary
 
-Provide a pair of intrinsic functions for hinting the likelyhood of branches being taken.
+Provide a pair of intrinsic functions for hinting the likelihood of branches being taken.
 
 # Motivation
 
 Branch prediction can have significant effects on the running time of some code. Especially tight
 inner loops which may be run millions of times. While in general programmers aren't able to
-effectively provide hints to the compiler, there are cases where the likelyhood of some branch
+effectively provide hints to the compiler, there are cases where the likelihood of some branch
 being taken can be known.
 
 For example: in arbitrary-precision arithmetic, operations are often performed in a base that is
diff --git a/text/1156-adjust-default-object-bounds.md b/text/1156-adjust-default-object-bounds.md
@@ -136,7 +136,7 @@ The rules for user-defined types from RFC 599 are altered as follows
 
 This is a breaking change, and hence it behooves us to evaluate the
 impact and describe a procedure for making the change as painless as
-possible. One nice propery of this change is that it only affects
+possible. One nice property of this change is that it only affects
 *defaults*, which means that it is always possible to write code that
 compiles both before and after the change by avoiding defaults in
 those cases where the new and old compiler disagree.
diff --git a/text/1183-swap-out-jemalloc.md b/text/1183-swap-out-jemalloc.md
@@ -31,13 +31,13 @@ the allocator.
 In addition to using an entirely separate allocator altogether, some Rust
 programs may want to simply instrument allocations or shim in additional
 functionality (such as memory tracking statistics). This is currently quite
-difficult to do, and would be accomodated with a custom allocation scheme.
+difficult to do, and would be accommodated with a custom allocation scheme.
 
 # Detailed design
 
 The high level design can be found [in this gist][gist], but this RFC intends to
 expound on the idea to make it more concrete in terms of what the compiler
-implementation will look like. A [sample implementaiton][impl] is available of
+implementation will look like. A [sample implementation][impl] is available of
 this section.
 
 [gist]: https://gist.github.com/alexcrichton/41c6aad500e56f49abda
diff --git a/text/1184-stabilize-no_std.md b/text/1184-stabilize-no_std.md
@@ -41,7 +41,7 @@ must be available in a stable fashion.
 
 # Detailed Design
 
-This RFC proposes a nuber of changes:
+This RFC proposes a number of changes:
 
 * Tweak the `#![no_std]` attribute slightly.
 * Introduce a `#![no_core]` attribute.
diff --git a/text/1199-simd-infrastructure.md b/text/1199-simd-infrastructure.md
@@ -180,7 +180,7 @@ data within vectors, giving super-linear speed-ups sometimes. As such,
 shuffles are exposed generally: intrinsics that represent arbitrary
 shuffles.
 
-This may violate the "one instruction per instrinsic" principal
+This may violate the "one instruction per intrinsic" principal
 depending on the shuffle, but rearranging SIMD vectors is extremely
 useful, and providing a direct intrinsic lets the compiler (a) do the
 programmers work in synthesising the optimal (short) sequence of
diff --git a/text/1200-cargo-install.md b/text/1200-cargo-install.md
@@ -63,7 +63,7 @@ directory).
 
 There are multiple methods of installing a new crate onto the system. The
 `cargo install` command with no arguments will install the current crate (as
-specifed by the current directory). Otherwise the `-p`, `--package`, `--git`,
+specified by the current directory). Otherwise the `-p`, `--package`, `--git`,
 and `--path` options all specify the source from which a crate is being
 installed. The `-p` and `--package` options will download crates from crates.io.
 
diff --git a/text/1214-projections-lifetimes-and-wf.md b/text/1214-projections-lifetimes-and-wf.md
@@ -266,7 +266,7 @@ the field `base_map` has the type `&'a mut HashMap<K,V>`, and this
 type is only valid if `K: 'a` and `V: 'a` hold. Since we don't know
 what `K` and `V` are, we have to surface this requirement in the form
 of a where-clause, so that users of the struct know that they must
-maintain this relationship in order for the struct to be interally
+maintain this relationship in order for the struct to be internally
 coherent.
 
 #### An aside: explicit WF requirements on types
@@ -551,7 +551,7 @@ Let's begin with a concrete example of an iterator type, like
 
     <Iter<'a,T> as Iterator>::Item
 
-or, in the more succint (but potentially ambiguous) form:
+or, in the more succinct (but potentially ambiguous) form:
 
     Iter<'a,T>::Item
 
@@ -680,7 +680,7 @@ sufficient.
 
 This complication is unfortunate, but to a large extent already exists
 with where-clauses and trait matching (see e.g. [#21974]). (Moreover,
-it seems to be inherent to the concept of assocated types, since they
+it seems to be inherent to the concept of associated types, since they
 take several inputs (the parameters to the trait) which may or may not
 be related to the actual type definition in question.)
 
@@ -867,7 +867,7 @@ struct Foo<'a, T:Eq> { .. }
 
 and a function type like `for<'a> fn(f: Foo<'a, T>)`, I still must
 show that `T: Eq` holds for that function to be well-formed.  This is
-because the condition which is geneated will be `'a ⊢ T: Eq`, but `'a`
+because the condition which is generated will be `'a ⊢ T: Eq`, but `'a`
 is not referenced there.
 
 #### Implied bounds
diff --git a/text/1216-bang-type.md b/text/1216-bang-type.md
@@ -249,7 +249,7 @@ So why do this? AFAICS there are 3 main reasons
     the argument. However there may be no sensible default type to use for `T`
     or, worse, they may not have any types at their disposal that implement
     `SomeTrait`. As the user in this case is only using `None`, a sensible
-    choice for `T` would be a type such that `Option<T>` can ony be `None`, ie.
+    choice for `T` would be a type such that `Option<T>` can only be `None`, ie.
     it would be nice to use `!`. If `!` has a trivial implementation of
     `SomeTrait` then the choice of `T` is truly irrelevant as this means `foo`
     doesn't use any associated types/lifetimes/constants or static methods of
diff --git a/text/1229-compile-time-asserts.md b/text/1229-compile-time-asserts.md
@@ -5,7 +5,7 @@
 
 # Summary
 
-If the constant evaluator encounters erronous code during the evaluation of
+If the constant evaluator encounters erroneous code during the evaluation of
 an expression that is not part of a true constant evaluation context a warning
 must be emitted and the expression needs to be translated normally.
 
diff --git a/text/1236-stabilize-catch-panic.md b/text/1236-stabilize-catch-panic.md
@@ -237,7 +237,7 @@ Let's take a look at each of these items in detail:
 
 * `impl PanicSafe for .. {}` - this makes this trait a marker trait, implying
   that a the trait is implemented for all types by default so long as the
-  consituent parts implement the trait.
+  constituent parts implement the trait.
 * `impl<T> !PanicSafe for &mut T {}` - this indicates that exception safety
   needs to be handled when dealing with mutable references. Thinking about the
   `recover` function, this means that the pointer could be modified inside the
@@ -344,7 +344,7 @@ properties are derived, adding a new marker trait can lead to a multiplicative
 increase in global complexity (as all types must consider the marker trait).
 
 With `PanicSafe`, however, it is expected that this is not the case. The
-`recover` function is not intented to be used commonly outside of FFI or thread
+`recover` function is not intended to be used commonly outside of FFI or thread
 pool-like abstractions. Within FFI the `PanicSafe` trait is typically not
 mentioned due to most types being relatively simple. Thread pools, on the other
 hand, will need to mention `AssertPanicSafe`, but will likely propagate panics
diff --git a/text/1238-nonparametric-dropck.md b/text/1238-nonparametric-dropck.md
@@ -106,7 +106,7 @@ parametricity of type-parameters.
 ### Changes to the Drop-Check Rule
 
 The Drop-Check Rule (both in its original form and as revised here)
-dicates when a lifetime `'a` must strictly outlive some value `v`,
+dictates when a lifetime `'a` must strictly outlive some value `v`,
 where `v` owns data of type `D`; the rule gave two circumstances where
 `'a` must strictly outlive the scope of `v`.
 
@@ -251,7 +251,7 @@ programmer to prove.
    above) was deliberately selected to be long and ugly, in order to
    discourage it from being stabilized in the future without at least
    some significant discussion. (Likewise, the acronym "UGEH" was
-   chosen for its likely pronounciation "ugh", again a reminder that
+   chosen for its likely pronunciation "ugh", again a reminder that
    we do not *want* to adopt this approach for the long term.)
 
 
@@ -468,7 +468,7 @@ a recursive property ensuring that during the extent of the call to `foo`,
 we will never invoke a function marked as `default` (and therefore, I *think*,
 will never even potentially invoke a method that has been specialized).
 
-It is also this second bullet that represents a signficant burden on
+It is also this second bullet that represents a significant burden on
 the destructor implementor. In particular, it immediately rules out
 using any library routine unless that routine has been marked as
 `#[unspecialized]`. The attribute is unlikely to be included on any
