Fix typos in RFCs 1501-1750

text/1510-cdylib.md

@@ -81,7 +81,7 @@ specifically:
 Rust's ephemeral and ill-defined "linkage model" is... well... ill defined and
 ephemeral. This RFC is an extension of this model, but it's difficult to reason
 about extending that which is not well defined. As a result there could be
-unforseen interactions between this output format and where it's used.
+unforeseen interactions between this output format and where it's used.
 
 # Alternatives
 [alternatives]: #alternatives

text/1535-stable-overflow-checks.md

@@ -37,7 +37,7 @@ It's another rather ad-hoc flag for modifying code generation.
 
 Like other such flags, this applies to the entire code unit,
 regardless of monomorphizations. This means that code generation for a
-single function can be diferent based on which code unit its
+single function can be different based on which code unit it's
 instantiated in.
 
 # Alternatives

text/1542-try-from.md

@@ -7,7 +7,7 @@
 [summary]: #summary
 
 The standard library provides the `From` and `Into` traits as standard ways to
-convert between types. However, these traits only support *infallable*
+convert between types. However, these traits only support *infallible*
 conversions. This RFC proposes the addition of `TryFrom` and `TryInto` traits
 to support these use cases in a standard way.
 

text/1543-integer_atomics.md

@@ -72,7 +72,7 @@ static ATOMIC: Mutex<(u64, u64)> = Mutex::new((0, 0));
 #[cfg(target_has_atomic = "64")]
 static COUNTER: AtomicU64 = AtomicU64::new(0);
 #[cfg(not(target_has_atomic = "64"))]
-static COUTNER: AtomicU32 = AtomicU32::new(0);
+static COUNTER: AtomicU32 = AtomicU32::new(0);
 ```
 
 Note that it is not necessary for an architecture to natively support atomic operations for all sizes (`i8`, `i16`, etc) as long as it is able to perform a `compare_exchange` operation with a larger size. All smaller operations can be emulated using that. For example a byte atomic can be emulated by using a `compare_exchange` loop that only modifies a single byte of the value. This is actually how LLVM implements byte-level atomics on MIPS, which only supports word-sized atomics native. Note that the out-of-bounds read is fine here because atomics are aligned and will never cross a page boundary. Since this transformation is performed transparently by LLVM, we do not need to do any extra work to support this.

text/1558-closure-to-fn-coercion.md

@@ -7,7 +7,7 @@
 [summary]: #summary
 
 A closure that does not move, borrow, or otherwise access (capture) local
-variables should be coercable to a function pointer (`fn`).
+variables should be coercible to a function pointer (`fn`).
 
 # Motivation
 [motivation]: #motivation

text/1560-name-resolution.md

@@ -64,7 +64,7 @@ important later.
   a macro.
 * Rust has multiple namespaces - types, values, and macros exist in separate
   namespaces (some items produce names in multiple namespaces). Imports
-  refer (implictly) to one or more names in different namespaces.
+  refer (implicitly) to one or more names in different namespaces.
 
   Note that all top-level (i.e., not parameters, etc.) path segments in a path
   other than the last must be in the type namespace, e.g., in `a::b::c`, `a` and
@@ -88,7 +88,7 @@ are resolved in different orders.
 
 Due to macro expansion, it is possible for a name to be resolved and then to
 become ambiguous, or (with rules formulated in a certain way) for a name to be
-resolved, then to be amiguous, then to be resolvable again (possibly to
+resolved, then to be ambiguous, then to be resolvable again (possibly to
 different bindings).
 
 Furthermore, there is some flexibility in the order in which macros can be

text/1561-macro-naming.md

@@ -54,7 +54,7 @@ foo!();
 macro! foo { ... }
 ```
 
-(Note, I'm using a hypothetical `macro!` defintion which I will define in a future
+(Note, I'm using a hypothetical `macro!` definition which I will define in a future
 RFC. The reader can assume it works much like `macro_rules!`, but with the new
 naming scheme).
 

text/1566-proc-macros.md

@@ -387,7 +387,7 @@ We could keep the existing system or remove procedural macros from Rust.
 We could have an AST-based (rather than token-based) system. This has major
 backwards compatibility issues.
 
-We could allow pluging in at later stages of compilation, giving macros access
+We could allow plugging in at later stages of compilation, giving macros access
 to type information, etc. This would allow some really interesting tools.
 However, it has some large downsides - it complicates the whole compilation
 process (not just the macro system), it pollutes the whole compiler with macro

text/1567-long-error-codes-explanation-normalization.md

@@ -131,7 +131,7 @@ Now let's take a full example:
 
 # Drawbacks
 
-This will make contributing slighty more complex, as there are rules to follow, whereas right now there are none.
+This will make contributing slightly more complex, as there are rules to follow, whereas right now there are none.
 
 # Alternatives
 

text/1574-more-api-documentation-conventions.md

@@ -8,7 +8,7 @@
 
 [RFC 505] introduced certain conventions around documenting Rust projects. This
 RFC augments that one, and a full text of the older one combined with these
-modfications is provided below.
+modifications is provided below.
 
 [RFC 505]: https://github.com/rust-lang/rfcs/blob/master/text/0505-api-comment-conventions.md
 

text/1589-rustc-bug-fix-procedure.md

@@ -239,7 +239,7 @@ of the compiler before they are finalized.
 Due to the lack of stable plugins, making changes to libsyntax can
 currently be quite disruptive to the ecosystem that relies on plugins.
 In an effort to ease this pain, we generally try to batch up such
-changes so that they occur all at once, rather than occuring in a
+changes so that they occur all at once, rather than occurring in a
 piecemeal fashion. In practice, this means that you should add:
 
     cc #31645 @Manishearth

text/1624-loop-break-value.md

@@ -204,7 +204,7 @@ loop {
 ### Result value
 
 A loop only yields a value if broken via some form of `break ...;` statement,
-in which case it yields the value resulting from the evaulation of the
+in which case it yields the value resulting from the evaluation of the
 statement's expression (`EXPR` above), or `()` if there is no `EXPR`
 expression.
 

text/1643-memory-model-strike-team.md

@@ -214,7 +214,7 @@ weighed:
 - **Optimization.** The stricter the rules, the more we can optimize.
   - on the other hand, rules that are overly strict may prevent people
     from writing unsafe code that they would like to write, ultimately
-    leading to slower exeution.
+    leading to slower execution.
 - **Comprehensibility.** It is important to strive for rules that end
   users can readily understand. If learning the rules requires diving
   into academic papers or using Coq, it's a non-starter.
@@ -243,7 +243,7 @@ should build on the examples from before, in that proposals can be
 weighed against their effect on the examples and optimizations.
 
 There will likely also be some feedback between this phase and the
-previosu: as new proposals are considered, that may generate new
+previous: as new proposals are considered, that may generate new
 examples that were not relevant previously.
 
 Note that even once a high-level design is adopted, it will be

text/1644-default-and-expanded-rustc-errors.md

@@ -52,7 +52,7 @@ make them difficult to use. Specifically, the current error format:
 * Repeats the file position on the left-hand side. This offers no additional information, but
 instead makes the error harder to read.
 * Prints messages about lines often out of order. This makes it difficult for the developer to
-glance at the error and recognize why the error is occuring
+glance at the error and recognize why the error is occurring
 * Lacks a clear visual break between errors. As more errors occur it becomes more difficult to tell
 them apart.
 * Uses technical terminology that is difficult for new users who may be unfamiliar with compiler

text/1681-macros-1.1.md

@@ -317,7 +317,7 @@ requirements of the compiler change, and even amongst platforms these details
 may be subtly different.
 
 The compiler will essentially consider `rustc-macro` crates as `--crate-type
-dylib -C prefer-dyanmic`. That is, compiled the same way they are today. This
+dylib -C prefer-dynamic`. That is, compiled the same way they are today. This
 namely means that these macros  will dynamically link to the same standard
 library as the compiler itself, therefore sharing resources like a global
 allocator, etc.
@@ -492,7 +492,7 @@ pub struct Foo {
   need to be careful to parenthesize token streams like this when it generates
   a stringified source.
 
-* By having separte library and macro crate support today (e.g. `serde` and
+* By having separate library and macro crate support today (e.g. `serde` and
   `serde_macros`) it's possible for there to be version skew between the two,
   making it tough to ensure that the two versions you're using are compatible
   with one another. This would be solved if `serde` itself could define or

text/1683-docs-team.md

@@ -39,7 +39,7 @@ However, RFCs are not only what subteams do. To quote the RFC:
 > * Delegating reviewer rights for the subteam area. The ability to r+ is not limited to team members, and in fact earning r+ rights is a good stepping stone toward team membership. Each team should set reviewing policy, manage reviewing rights, and ensure that reviews take place in a timely manner. (Thanks to Nick Cameron for this suggestion.)
 
 The first two are about RFCs themselves, but the second two are more pertinent to documentation. In particular,
-deciding who gets `r+` rights is important. A lack of clarity in this area has been unfortuante, and has led to a
+deciding who gets `r+` rights is important. A lack of clarity in this area has been unfortunate, and has led to a
 chicken and egg situation: without a documentation team, it's unclear how to be more involved in working on Rust's
 documentation, but without people to be on the team, there's no reason to form a team. For this reason, I think
 a small initial team will break this logjam, and provide room for new contributors to grow.

text/1717-dllimport.md

@@ -117,7 +117,7 @@ meaning that it will be common that these attributes are left off by accident.
   - This attribute would duplicate the information already provided by
     `#[link(kind="...")]`.
   - It is not always known whether `#[dllimport]` is needed. Native
-    libraires are not always known whether they're linked dynamically or
+    libraries are not always known whether they're linked dynamically or
     statically (e.g. that's what a build script decides), so `dllimport`
     will need to be guarded by `cfg_attr`.
 

text/1725-unaligned-access.md

@@ -50,7 +50,7 @@ pub unsafe fn write_unaligned<T>(p: *mut T, v: T) {
 # Drawbacks
 [drawbacks]: #drawbacks
 
-There functions aren't *stricly* necessary since they are just convenience wrappers around `ptr::copy_nonoverlapping`.
+There functions aren't *strictly* necessary since they are just convenience wrappers around `ptr::copy_nonoverlapping`.
 
 # Alternatives
 [alternatives]: #alternatives

text/1728-north-star.md

@@ -157,7 +157,7 @@ Key terminology used in this RFC:
 
 - _release cycle milestone_ - All goals have estimates for completion, placed on
   milestones that correspond to the 6 week release cycle. These milestones are
-  timed to corrspond to a release cycle, but don't represent a specific
+  timed to correspond to a release cycle, but don't represent a specific
   release. That is, work toward the current nightly, the current beta, or even
   that doesn't directly impact a specific release, all goes into the release
   cycle milestone corresponding to the time period in which the work is
@@ -278,7 +278,7 @@ to the appropriate milestone. Some goals may be expected to be completed in
 the distant future, and these do not need to be assigned a milestone.
 
 The release cycle milestone corresponds to a six week period of time and
-contains the work done during that time. It does not correspend to a specific
+contains the work done during that time. It does not correspond to a specific
 release, nor do the goals assigned to it need to result in a stable feature
 landing in any specific release.
 

text/1733-trait-alias.md

@@ -57,7 +57,7 @@ impl<T> FooBackend for T where T: Foo<Backend> {}
 
 With that, it’s now possible to pass an object that implements `Foo<Backend>` to a function
 expecting a `FooBackend`. However, what about impl blocks? What happens if we implement only
-`FooBackend`? Well, we cannot, because the trait explicitely states that we need to implement
+`FooBackend`? Well, we cannot, because the trait explicitly states that we need to implement
 `Foo<Backend>`. We hit a problem here. The problem is that even though there’s a compatibility at
 the `trait bound` level between `Foo<Backend>` and `FooBackend`, there’s none at the `impl` level,
 so all we’re left with is implementing `Foo<Backend>` – that will also provide an implementation for
@@ -325,7 +325,7 @@ There’s currently no alternative to the impl problem described here.
 
 ## `ConstraintKinds`
 
-Similar to GHC’s `ContraintKinds`, we could declare an entire predicate as a reified list of
+Similar to GHC’s `ConstraintKinds`, we could declare an entire predicate as a reified list of
 constraints, instead of creating an alias for a set of supertraits and predicates. Syntax would be
 something like `constraint Foo<T> = T: Bar, Vec<T>: Baz;`, used as `fn quux<T>(...) where Foo<T> { ... }`
 (i.e. direct substitution). Trait object usage is unclear.