Fix typos in RFCs 1751-2000

Author: jhpratt

text/1824-crates.io-default-ranking.md

@@ -74,7 +74,7 @@ A few assumptions we made:
 ## Order by recent downloads
 
 Through the iterations of this RFC, there was no consensus around a way to order
-crates that would be useful, understandable, resistent to being gamed, and not
+crates that would be useful, understandable, resistant to being gamed, and not
 require work of curators, reviewers, or moderators. Furthermore, different
 people in different situations may value different aspects of crates.
 
@@ -272,7 +272,7 @@ These would be displayed as badges on lists of crates.
 
 These levels would not have any time commitments attached to them-- maintainers
 who would like to batch changes into releases every 6 months could report
-"actively developed" just as much as mantainers who like to release every 6
+"actively developed" just as much as maintainers who like to release every 6
 weeks. This would need to be clearly communicated to set crate user
 expectations properly.
 

text/1828-rust-bookshelf.md

@@ -73,18 +73,18 @@ book will run when developers do `x.py check`. This is similar to how, today,
 Traivs runs a subset of the tests, but buildbot runs all of them.
 
 The landing page on doc.rust-lang.org will show off the full bookshelf, to let
-people find the documenation they need. It will also link to their respective
+people find the documentation they need. It will also link to their respective
 repositories.
 
 Finally, this creates a path for more books in the future: "the FFI Book" would
 be one example of a possibility for this kind of thing. The docs team will
-develop critera for accepting a book as part of the official project.
+develop criteria for accepting a book as part of the official project.
 
 # How We Teach This
 [how-we-teach-this]: #how-we-teach-this
 
 The landing page on doc.rust-lang.org will show off the full bookshelf, to let
-people find the documenation they need. It will also link to their respective
+people find the documentation they need. It will also link to their respective
 repositories.
 
 # Drawbacks

text/1845-shared-from-slice.md

@@ -74,7 +74,7 @@ Providing these implementations in the current state of Rust requires substantia
 
 ## [`RcBox`][RcBox] is not public
 
-Furthermore, since [`RcBox`][RcBox] is not exposed publically from [`std::rc`][std::rc], one can't make an implementation outside of the standard library for this without making assumptions about the internal layout of [`Rc`][Rc]. The alternative is to roll your own implementation of [`Rc`][Rc] in its entirity - but this in turn requires using a lot of feature gates, which makes using this on stable Rust in the near future unfeasible.
+Furthermore, since [`RcBox`][RcBox] is not exposed publicly from [`std::rc`][std::rc], one can't make an implementation outside of the standard library for this without making assumptions about the internal layout of [`Rc`][Rc]. The alternative is to roll your own implementation of [`Rc`][Rc] in its entirety - but this in turn requires using a lot of feature gates, which makes using this on stable Rust in the near future unfeasible.
 
 ## For [`Arc`][Arc]
 
@@ -479,7 +479,7 @@ The main drawback would be increasing the size of the standard library.
 
 1. Only implement this for [`T: Copy`][Copy] and skip [`T: Clone`][Clone].
 2. Let other libraries do this. This has the problems explained in the [motivation]
-section above regarding [`RcBox`][RcBox] not being publically exposed as well as
+section above regarding [`RcBox`][RcBox] not being publicly exposed as well as
 the amount of feature gates needed to roll ones own [`Rc`][Rc] alternative - for
 little gain.
 3. Only implement this for [`Rc`][Rc] and skip it for [`Arc`][Arc].

text/1857-stabilize-drop-order.md

@@ -44,7 +44,7 @@ code (which could rely on the new drop order).
 
 Both requirements seem quite difficult, if not impossible, to meet. Even in case
 we figured out how to meet those requirements, the complexity of the approach would
-probably outweight the current complexity of having a non-intuitive drop order.
+probably outweigh the current complexity of having a non-intuitive drop order.
 
 Finally, in case people really dislike the current drop order, it may still
 be possible to introduce alternative, opt-in, drop orders in a backwards

text/1859-try-trait.md

@@ -75,7 +75,7 @@ and hence could be changed back to be more in line with this RFC.)
 
 The existing `try!` macro and `?` operator already allow a limit
 amount of type conversion, specifically in the error case. That is, if
-you apply `?` to a value of type `Result<T, E>`, the surrouding
+you apply `?` to a value of type `Result<T, E>`, the surrounding
 function can have some other return type `Result<U, F>`, so long as
 the error types are related by the `From` trait (`F: From<E>`). The
 idea is that if an error occurs, we will wind up returning
@@ -119,7 +119,7 @@ help ensure that "accidental" interconversion does not occur.
 ### Playground
 
 Note: if you wish to experiment,
-[this Rust playgroud link](https://play.rust-lang.org/?gist=9ef8effa0c1c81bc8bb8dccb07505c54&version=stable&backtrace=0)
+[this Rust playground link](https://play.rust-lang.org/?gist=9ef8effa0c1c81bc8bb8dccb07505c54&version=stable&backtrace=0)
 contains the traits and impls defined herein.
 
 ### Desugaring and the `Try` trait

text/1884-unstable-sort.md

@@ -123,7 +123,7 @@ assert!(v == [1, 2, -3, 4, -5]);
 
 ### Implementation
 
-Proposed implementaton is available in the [pdqsort][stjepang-pdqsort] crate.
+Proposed implementation is available in the [pdqsort][stjepang-pdqsort] crate.
 
 **Q: Why choose this particular sort algorithm?**<br>
 A: First, let's analyse what unstable sort algorithms other languages use:

text/1892-uninitialized-uninhabited.md

@@ -146,9 +146,9 @@ actually unsafe - where we have to assert to the compiler that we have a valid
 value. And we only ever tell the compiler we have a value of type `T` where we
 know we actually do have a value of type `T`. As such, this is fine to use with
 any `T`, including `!`. If the callback diverges then it's not possible to get
-to the `unsafe` block and try to read the non-existant value.
+to the `unsafe` block and try to read the non-existent value.
 
-Given that it's so easy for code using `uninitialzed` to hide bugs like this,
+Given that it's so easy for code using `uninitialized` to hide bugs like this,
 and given that there's a better alternative, this RFC proposes deprecating
 `uninitialized` and introducing the `MaybeUninit` type into the standard
 library as a replacement.

text/1909-unsized-rvalues.md

@@ -189,14 +189,14 @@ pub trait Clone {
 }
 ```
 
-That would be a backwards-compatability-breaking change, because today `T: Clone + ?Sized` (or of course `Self: Clone` in a trait context, with no implied `Self: Sized`) implies that `T: Sized`, but it might be that its impact is small enough to allow (and even if not, it might be worth it for Rust 2.0).
+That would be a backwards-compatibility-breaking change, because today `T: Clone + ?Sized` (or of course `Self: Clone` in a trait context, with no implied `Self: Sized`) implies that `T: Sized`, but it might be that its impact is small enough to allow (and even if not, it might be worth it for Rust 2.0).
 
 # Unresolved questions
 [unresolved]: #unresolved-questions
 
 How can we mitigate the risk of unintended unsized or large allocas? Note that the problem already exists today with large structs/arrays. A MIR lint against large/variable stack sizes would probably help users avoid these stack overflows. Do we want it in Clippy? rustc?
 
-How do we handle truely-unsized DSTs when we get them? They can theoretically be passed to functions, but they can never be put in temporaries.
+How do we handle truly-unsized DSTs when we get them? They can theoretically be passed to functions, but they can never be put in temporaries.
 
 Accumulative allocas (aka `'fn` borrows) are beyond the scope of this RFC.
 

text/1966-unsafe-pointer-reform.md

@@ -53,7 +53,7 @@ However these static functions are fairly cumbersome in the common case, where y
 
 ## Signed Offset
 
-The cast in `ptr.offset(idx as isize)` is unnecessarily annoying. Idiomatic Rust code uses unsigned offsets, but low level code is forced to constantly cast those offsets. To understand why this interface is designed as it is, some background is neeeded.
+The cast in `ptr.offset(idx as isize)` is unnecessarily annoying. Idiomatic Rust code uses unsigned offsets, but low level code is forced to constantly cast those offsets. To understand why this interface is designed as it is, some background is needed.
 
 `offset` is directly exposing LLVM's `getelementptr` instruction, with the `inbounds` keyword. `wrapping_offset` removes the `inbounds` keyword. `offset` takes a signed integer, because that's what GEP exposes. It's understandable that we've been conservative here; GEP is so confusing that it has an [entire FAQ](http://llvm.org/docs/GetElementPtr.html).
 

text/1969-cargo-prepublish.md

@@ -339,7 +339,7 @@ section! For example these two sections are equivalent:
 log = { git = 'https://github.com/rust-lang-nursery/log' }
 ```
 
-This is not accidental! The intial development of the `[patch]` feature was
+This is not accidental! The initial development of the `[patch]` feature was
 actually focused on prepublishing dependencies and was called `[prepublish]`,
 but while discussing it a conclusion was reached that `[prepublish]` already
 allowed replacing existing versions in a registry, but issued a warning when
@@ -368,7 +368,7 @@ The mechanism itself is straightforward enough that a handful of examples (as in
 this RFC) is generally enough to explain it. In the docs, these examples should
 be spelled out in greater detail.
 
-Most notably, however, the [overriding dependenices][over] section of Cargo's
+Most notably, however, the [overriding dependencies][over] section of Cargo's
 documentation will be rewritten to primarily mention `[patch]`, but
 `[replace]` will be mentioned still with a recommendation to use `[patch]`
 instead if possible.