Fix typos in RFCs 1251-1500

text/1252-open-options.md

@@ -557,7 +557,7 @@ If you read a file sequentially the read-ahead is beneficial, for completely
 random access it can become a penalty.
 
 - `Default` uses the generally good heuristics of the operating system.
-- `Sequential` indicates sequential but not neccesary consecutive access.
+- `Sequential` indicates sequential but not necessary consecutive access.
   With this the os may increase the amount of data that is read ahead.
 - `Random` indicates mainly random access. The os may disable its read-ahead
   cache.
@@ -611,7 +611,7 @@ This guarantees every write will not return before the data is written to disk.
 These options improve reliability as and you can never accidentally forget a
 sync.
 
-Whether perfermance with these options is worse than with the stand-alone
+Whether performance with these options is worse than with the stand-alone
 functions is hard to say. With these options the data maybe has to be
 synchronised more often. But the stand-alone functions often sync outstanding
 writes to all files, while the options possibly sync only the current file.

text/1257-drain-range-2.md

@@ -19,7 +19,7 @@ from a vector.
 
 `drain` thus serves both to consume all or some elements from a collection without
 consuming the collection itself. The ranged `drain` allows bulk removal of
-elements, more efficently than any other safe API.
+elements, more efficiently than any other safe API.
 
 # Detailed design
 
@@ -51,7 +51,7 @@ The following collections need updated implementations:
 does.
 
 `LinkedList` should implement `.drain(range)` for index ranges. Just
-like the other seqences, this is a `O(n)` operation, and `LinkedList` already
+like the other sequences, this is a `O(n)` operation, and `LinkedList` already
 has other indexed methods (`.split_off()`).
 
 ## `BTreeMap` and `BTreeSet`

text/1291-promote-libc.md

@@ -264,7 +264,7 @@ value, so even if you were restricted to a particular subset it's not clear that
 a program would automatically be more portable.
 
 That being said, it would still be useful to have these abstractions to *some
-degree*, but the filp side is that it's easy to build this sort of layer on top
+degree*, but the flip side is that it's easy to build this sort of layer on top
 of `libc` as designed here externally on crates.io. For example `extern crate
 posix` could just depend on `libc` and reexport all the contents for the
 POSIX standard, perhaps with tweaked signatures here and there to work better
@@ -288,7 +288,7 @@ in the immedidate future.
   unclear how much portability using these standards actually buys you.
 
 * The crate could be split up into multiple crates which represent an exact
-  correspondance to system libraries, but this has the downside of using common
+  correspondence to system libraries, but this has the downside of using common
   functions available on both OSX and Linux would require at least two `extern
   crate` directives and dependencies.
 

text/1298-incremental-compilation.md

@@ -541,7 +541,7 @@ recompiling all of them. Our plan is to phase span support in incrementally:
    particular AST node (relative to the root of the item). Since we
    are hashing the structure of the AST, we know the AST from the
    previous and current compilation will match, and thus we can
-   compute the current span by finding tha corresponding AST node and
+   compute the current span by finding the corresponding AST node and
    loading its span. This will require some refactoring and work however.
    
 <a id="optimization"></a>

text/1317-ide.md

@@ -280,7 +280,7 @@ that different clients will not benefit from each other's innovations.
 
 The RLS could do more - actually perform some of the processing tasks usually
 done by IDEs (such as editing source code) or other tools (refactoring,
-reformating, etc.).
+reformatting, etc.).
 
 
 # Unresolved questions
@@ -298,5 +298,5 @@ What kind of IPC protocol to use? HTTP is popular and simple to deal with. It's
 platform-independent and used in many similar pieces of software. On the other
 hand it is heavyweight and requires pulling in large libraries, and requires
 some attention to security issues. Alternatives are some kind of custom
-prototcol, or using a solution like Thrift. My prefernce is for HTTP, since it
+protocol, or using a solution like Thrift. My preference is for HTTP, since it
 has been proven in similar situations.

text/1327-dropck-param-eyepatch.md

@@ -14,7 +14,7 @@ parameters the destructor is guaranteed not to access.
 
 Specifically, this RFC proposes adding the capability to attach
 attributes to the binding sites for generic parameters (i.e. lifetime
-and type paramters). Atop that capability, this RFC proposes adding a
+and type parameters). Atop that capability, this RFC proposes adding a
 `#[may_dangle]` attribute that indicates that a given lifetime or type
 holds data that must not be accessed during the dynamic extent of that
 `drop` invocation.
@@ -153,7 +153,7 @@ to be proposed in a follow-up RFC.
 Having said that, here is the proposed short-term solution:
 
  1. Add the ability to attach attributes to syntax that binds formal
-    lifetime or type parmeters. For the purposes of this RFC, the only
+    lifetime or type parameters. For the purposes of this RFC, the only
     place in the syntax that requires such attributes are `impl`
     blocks, as in `impl<T> Drop for Type<T> { ... }`
 
@@ -531,7 +531,7 @@ Drawbacks of fn-drop-with-where-clauses:
 
     I actually do not give this drawback much weight; resolving this
     may be merely a matter of just trying to do it: e.g., build up the
-    set of where-clauses when we make the ADT's representatin, and
+    set of where-clauses when we make the ADT's representations, and
     then have `dropck` insert instantiate and insert them as needed.
 
   * It might have the wrong ergonomics for developers: It seems bad to

text/1398-kinds-of-allocators.md

@@ -99,7 +99,7 @@ we summarize the high-level points of the `Allocator` API.
 individual sections of code.)
 
  * Basic implementation of the trait requires just two methods
-   (`alloc` and `dealloc`). You can get an initial implemention off
+   (`alloc` and `dealloc`). You can get an initial implementation off
    the ground with relatively little effort.
 
  * All methods that can fail to satisfy a request return a `Result`
@@ -126,7 +126,7 @@ individual sections of code.)
 
      * Heterogenous structure; e.g. `layout1.extend(layout2)`,
 
-     * Homogenous array types: `layout.repeat(n)` (for `n: usize`),
+     * Homogeneous array types: `layout.repeat(n)` (for `n: usize`),
 
      * There are packed and unpacked variants for the latter two methods.
 
@@ -270,7 +270,7 @@ Since clients are not allowed to have blocks that outlive their
 associated allocator (see the [lifetimes][] section),
 it is sound for us to always drop the backing storage for an allocator
 when the allocator itself is dropped
-(regardless of what sequence of `alloc`/`dealloc` interactions occured
+(regardless of what sequence of `alloc`/`dealloc` interactions occurred
 with the allocator's clients).
 
 ```rust
@@ -470,7 +470,7 @@ almost certainly require a *default type*: `Vec<T:
 A:Allocator=HeapAllocator>` and
 `HashMap<K,V,A:Allocator=HeapAllocator>`.
 
-Default type parameters themselves, in the context of type defintions,
+Default type parameters themselves, in the context of type definitions,
 are a stable part of the Rust language.
 
 However, the exact semantics of how default type parameters interact
@@ -640,7 +640,7 @@ in a formal manner, in the style of [IETF RFC 2119][].)
 
  5. (for allocator impls and clients) if an allocator is cloneable, the 
     client *can assume* that all clones
-    are interchangably compatible in terms of their memory blocks: if
+    are interchangeably compatible in terms of their memory blocks: if
     allocator `a2` is a clone of `a1`, then one can allocate a block
     from `a1` and return it to `a2`, or vice versa, or use `a2.realloc`
     on the block, et cetera.
@@ -884,7 +884,7 @@ The Rust project has control over the `libstd` provided allocators, so
 the team can adapt them as necessary to fit the needs of whatever GC
 designs come around. But the same is not true for user-defined
 allocators: we want to ensure that adding support for them does not
-inadvertantly kill any chance for adding GC later.
+inadvertently kill any chance for adding GC later.
 
 ### The inspiration for Layout
 
@@ -1009,7 +1009,7 @@ few motivating examples that *are* clearly feasible and useful.
      offset) versus `Layout::array` (where the offset is derivable from
      the input `T`).
 
-   * Such a constraint would have precendent; in particular, the
+   * Such a constraint would have precedent; in particular, the
      `aligned_alloc` function of C11 requires the given size
      be a multiple of the alignment.
 
@@ -1072,7 +1072,7 @@ few motivating examples that *are* clearly feasible and useful.
       that reborrowing machinery is available to the client code.)
 
      Put more simply, requiring that allocators implement `Clone` means
-     that it will *not* be pratical to do
+     that it will *not* be practical to do
      `impl<'a> Allocator for &'a mut MyUniqueAlloc`.
 
      By using `&mut self` for the allocation methods, we can encode
@@ -1204,7 +1204,7 @@ few motivating examples that *are* clearly feasible and useful.
 
 # Change History
 
-* Changed `fn usable_size` to return `(l, m)` rathern than just `m`.
+* Changed `fn usable_size` to return `(l, m)` rather than just `m`.
 
 * Removed `fn is_transient` from `trait AllocError`, and removed discussion
   of transient errors from the API.
@@ -1583,7 +1583,7 @@ impl Layout {
     /// Creates a layout describing the record for `self` followed by
     /// `next` with no additional padding between the two. Since no
     /// padding is inserted, the alignment of `next` is irrelevant,
-    /// and is not incoporated *at all* into the resulting layout.
+    /// and is not incorporated *at all* into the resulting layout.
     ///
     /// Returns `(k, offset)`, where `k` is layout of the concatenated
     /// record and `offset` is the relative location, in bytes, of the
@@ -1654,7 +1654,7 @@ impl Layout {
     /// Creates a layout describing the record for `self` followed by
     /// `next` with no additional padding between the two. Since no
     /// padding is inserted, the alignment of `next` is irrelevant,
-    /// and is not incoporated *at all* into the resulting layout.
+    /// and is not incorporated *at all* into the resulting layout.
     ///
     /// Returns `(k, offset)`, where `k` is layout of the concatenated
     /// record and `offset` is the relative location, in bytes, of the
@@ -1715,7 +1715,7 @@ pub enum AllocErr {
     /// satisfying the original request. This condition implies that
     /// such an allocation request will never succeed on the given
     /// allocator, regardless of environment, memory pressure, or
-    /// other contextual condtions.
+    /// other contextual conditions.
     ///
     /// For example, an allocator that does not support zero-sized
     /// blocks can return this error variant.
@@ -1810,7 +1810,7 @@ pub unsafe trait Allocator {
     /// practice this means implementors should eschew allocating,
     /// especially from `self` (directly or indirectly).
     ///
-    /// Implementions of this trait's allocation methods are discouraged
+    /// Implementations of this trait's allocation methods are discouraged
     /// from panicking (or aborting) in the event of memory exhaustion;
     /// instead they should return an appropriate error from the
     /// invoked method, and let the client decide whether to invoke

text/1422-pub-restricted.md

@@ -399,7 +399,7 @@ are unrestricted?
 The simple answer is: No, associated items are not implicitly `pub`;
 at least, not in general. (They are not in general implicitly `pub`
 today either, as discussed in [RFC 136][when public (RFC 136)].)
-(If they were implictly `pub`, things would be difficult; further
+(If they were implicitly `pub`, things would be difficult; further
 discussion in attached [appendix][associated items digression].)
 
 [when public (RFC 136)]: https://github.com/rust-lang/rfcs/blob/master/text/0136-no-privates-in-public.md#when-is-an-item-public
@@ -756,7 +756,7 @@ innards of other modules.
  * "Fix" the mental model of privacy (if necessary) without extending
    the language.
 
-   The alternative is bascially saying: "Our existing system is fine; all
+   The alternative is basically saying: "Our existing system is fine; all
    of the problems with it are due to bugs in the implementation"
 
    I am sympathetic to this response. However, I think it doesn't
@@ -865,7 +865,7 @@ pub mod a {
 
 However, since `b` is non-`pub`, its `pub` items and re-exports are
 solely accessible via the subhierarchy of its module parent (i.e.,
-`mod a`, as long as no entity attempts to re-export them to a braoder
+`mod a`, as long as no entity attempts to re-export them to a broader
 scope.
 
 In other words, in some sense `mod b { pub use item; }` *could*
@@ -930,7 +930,7 @@ mod m {
         // What is reexported here?
         // Just `S4`?
         // Anything in `m` visible
-        //  to `n` (which is not consisent with the current treatment of
+        //  to `n` (which is not consistent with the current treatment of
         `pub` by globs).
 
         pub use m::*;

text/1432-replace-slice.md

@@ -135,7 +135,7 @@ Then, depending on the real length of the iterator:
 [drawbacks]: #drawbacks
 
 Same as for any addition to `std`:
-not every program needs it, and standard library growth has a maintainance cost.
+not every program needs it, and standard library growth has a maintenance cost.
 
 # Alternatives
 [alternatives]: #alternatives

text/1445-restrict-constants-in-patterns.md

@@ -165,7 +165,7 @@ are two main disadvantages:
    permit associated constants or generic integers to be used in a
    match statement.
 
-#### Disadvantage: Weakened abstraction bounary
+#### Disadvantage: Weakened abstraction boundary
 
 The single biggest concern with structural equality is that it
 introduces two distinct notions of equality: the `==` operator, based

text/1479-unix-socket.md

@@ -70,7 +70,7 @@ impl UnixStream {
     ///
     /// The returned `UnixStream` is a reference to the same stream that this
     /// object references. Both handles will read and write the same stream of
-    /// data, and options set on one stream will be propogated to the other
+    /// data, and options set on one stream will be propagated to the other
     /// stream.
     pub fn try_clone(&self) -> io::Result<UnixStream> {
         ...
@@ -301,7 +301,7 @@ impl UnixDatagram {
     ///
     /// The returned `UnixDatagram` is a reference to the same stream that this
     /// object references. Both handles will read and write the same stream of
-    /// data, and options set on one stream will be propogated to the other
+    /// data, and options set on one stream will be propagated to the other
     /// stream.
     pub fn try_clone(&self) -> io::Result<UnixStream> {
         ...