Fix minor typos

Author: pnehrer

text/0019-opt-in-builtin-traits.md

@@ -80,7 +80,7 @@ people avoid `Cell` and `Rc` when not needed. Explicit opt-in
 threatens that future, however, because fewer types will implement
 `Share`, even if they are in fact threadsafe.
 
-With respect to extensibility, it is partiularly worrisome that if a
+With respect to extensibility, it is particularly worrisome that if a
 library forgets to implement `Send` or `Share`, downstream clients are
 stuck. They cannot, for example, use a newtype wrapper, because it
 would be illegal to implement `Send` on the newtype. This implies that
@@ -123,7 +123,7 @@ makes them *less* built-in, but still requires custom logic in the
 `Safe` or `Share` are implemented.
 
 After the changes I propose, the only traits which would be
-specicially understood by the compiler are `Copy` and `Sized`. I
+specifically understood by the compiler are `Copy` and `Sized`. I
 consider this acceptable, since those two traits are intimately tied
 to the core Rust type system, unlike `Send` and `Share`.
 
@@ -198,7 +198,7 @@ that `T` implements `Foo`. This allows recursive types like
     struct List<T> { data: T, next: Option<List<T>> }
 
 to be checked successfully. Otherwise, we would recursive infinitely.
-(This procedure is directly analagous to what the existing
+(This procedure is directly analogous to what the existing
 `TypeContents` code does.)
 
 Note that there exist types that expand to an infinite tree of types.
@@ -367,20 +367,20 @@ traits. In effect, opt-in is anti-modular in its own way.
 To be more specific, imagine that library A wishes to define a
 `Untainted` trait, and it specifically opts out of `Untainted` for
 some base set of types. It then wishes to have routines that only
-operate on `Untained` data. Now imagine that there is some other
+operate on `Untainted` data. Now imagine that there is some other
 library B that defines a nifty replacement for `Vector`,
 `NiftyVector`. Finally, some library C wishes to use a
 `NiftyVector<uint>`, which should not be considered tainted, because
 it doesn't reference any tainted strings. However, `NiftyVector<uint>`
 does not implement `Untainted` (nor can it, without either library A
-or libary B knowing about one another). Similar problems arise for any
+or library B knowing about one another). Similar problems arise for any
 trait, of course, due to our coherence rules, but often they can be
 overcome with new types. Not so with `Send` and `Share`.
 
 #### Other use cases
 
 Part of the design involves making space for other use cases. I'd like
-to skech out how some of those use cases can be implemented briefly.
+to sketch out how some of those use cases can be implemented briefly.
 This is not included in the *Detailed design* section of the RFC
 because these traits generally concern other features and would be
 added under RFCs of their own.

text/0040-libstd-facade.md

@@ -81,7 +81,7 @@ many locations.
 #### Strings
 
 In a post-DST world, the string type will actually be a library-defined type,
-`Str` (or similarly named). Strings will no longer be a lanuage feature or a
+`Str` (or similarly named). Strings will no longer be a language feature or a
 language-defined type. This implies that any methods on strings must be in the
 same crate that defined the `Str` type, or done through extension traits.
 
@@ -383,7 +383,7 @@ various environments seems beneficial.
   etc. This route has may have the problem of "multiple standard libraries"
   in that code compatible with the "libc libstd" is not necessarily compatible
   with the "no libc libstd". Asserting that a crate is compatible with multiple
-  profiles would involve requiring multiple compliations.
+  profiles would involve requiring multiple compilations.
 
 * Removing libstd entirely. If the standard library is simply a facade, the
   compiler could theoretically only inject a select number of crates into the

text/0048-traits.md

@@ -224,7 +224,7 @@ we find we need more type information to proceed with some
 type-overloaded operation, rather than reporting an error we can try
 and resolve pending constraints. If that helps give more information,
 we can carry on. Once we reach the end of the function, we must then
-resolve all pending constriants that have not yet been resolved for
+resolve all pending constraints that have not yet been resolved for
 some other reason.
 
 Note that there is some interaction with the distinction between input
@@ -527,7 +527,7 @@ slightly modified example:
 As before, we'll start out with a type of `Monster`, but this type the
 method `move_to_room()` has a receiver type of `Gc<Monster>`. This
 doesn't match cases 1, 2, or 3, so we proceed to case 4 and *unwind*
-by one adustment. Since the most recent adjustment was to deref from
+by one adjustment. Since the most recent adjustment was to deref from
 `Gc<Monster>` to `Monster`, we are left with a type of
 `Gc<Monster>`. We now search again. This time, we match case 1. So the
 final result is `Mob::move_to_room(victim, room)`. This last case is
@@ -660,7 +660,7 @@ extent.
 ## The "resolve" algorithm
 
 The basis for the coherence check, method lookup, and vtable lookup
-algoritms is the same function, called *RESOLVE*. The basic idea is
+algorithms is the same function, called *RESOLVE*. The basic idea is
 that it takes a set of obligations and tries to resolve them. The result
 is four sets:
 

text/0049-match-arm-attributes.md

@@ -9,7 +9,7 @@ Allow attributes on match arms.
 # Motivation
 
 One sometimes wishes to annotate the arms of match statements with
-attributes, for example with conditional complilation `#[cfg]`s or
+attributes, for example with conditional compilation `#[cfg]`s or
 with branch weights (the latter is the most important use).
 
 For the conditional compilation, the work-around is duplicating the

text/0068-const-unsafe-pointers.md

@@ -104,7 +104,7 @@ the language, `const`.
 
 * How much can the compiler help out when coercing `&mut T` to `*mut T`? As
   previously stated, the source pointer `&mut T` is consumed during the
-  coerction (it's already a linear type), but this can lead to some unexpected
+  coercion (it's already a linear type), but this can lead to some unexpected
   results:
 
       extern {

text/0092-struct-grammar.md

@@ -18,7 +18,7 @@ literals to not require the `:` (e.g., if we allow empty structs to be written
 with braces, or if we allow struct literals to unify field names to local
 variable names, as has been suggested in the past and which we currently do for
 struct literal patterns). We should also be able to give better error messages
-today if users make these mistakes. More worringly, we might come up with some
+today if users make these mistakes. More worryingly, we might come up with some
 language feature in the future which is not predictable now and which breaks
 with the current system.
 

text/0100-partial-cmp.md

@@ -4,7 +4,7 @@
 
 # Summary
 
-Add a `partial_cmp` method to `PartialOrd`, analagous to `cmp` in `Ord`.
+Add a `partial_cmp` method to `PartialOrd`, analogous to `cmp` in `Ord`.
 
 # Motivation
 
@@ -93,7 +93,7 @@ should be. It would also require more work to implement `PartialOrd` once the
 currently planned `cmp` reform has finished as noted above.
 
 `partial_cmp` could just be called `cmp`, but it seems like UFCS would need to
-be implemented first for that to be workrable.
+be implemented first for that to be workable.
 
 # Unresolved questions
 

text/0109-remove-crate-id.md

@@ -72,14 +72,14 @@ Note that both the `<version>` and the `<hash>` are missing by default. The
 and the `<hash>` was removed to make the output filename predictable.
 
 The three original goals can still be satisfied with this simplified naming
-scheme. As explained in th enext section, the compiler's "glob pattern" when
+scheme. As explained in the next section, the compiler's "glob pattern" when
 searching for a crate named `foo` will be `libfoo*.rlib`, which will help
 rationalize some of these conclusions.
 
 * Libraries of the same name can exist next to one another because they can be
   manually renamed to have extra data after the `libfoo`, such as the version.
 * Libraries of the same name and version, but different source, can also exist
-  by modifing what comes after `libfoo`, such as including a hash.
+  by modifying what comes after `libfoo`, such as including a hash.
 * Rust does not need to occupy a privileged namespace as the default rust
   installation would include hashes in all the filenames as necessary. More on
   this later.
@@ -148,7 +148,7 @@ not compile a crate with two different versions of an upstream crate.
 Additionally, cargo could not substitute `libfast-json` for `libslow-json` at
 compile time (assuming they have the same API).
 
-To accomodate an "expert mode" in rustc, the compiler will grow a new command
+To accommodate an "expert mode" in rustc, the compiler will grow a new command
 line flag of the form:
 
 ```

text/0115-rm-integer-fallback.md

@@ -51,7 +51,7 @@ enum Color { Red = 0, Green = 1, Blue = 2 }
 ```
 
 Currently, an unsuffixed integer defaults to `int`. Instead, we will
-only require enum descriminants primitive integers of unspecified
+only require enum discriminants primitive integers of unspecified
 type; assigning an integer to an enum will behave as if casting from
 from the type of the integer to an unsigned integer with the size of
 the enum discriminant.

text/0130-box-not-special.md

@@ -12,7 +12,7 @@ Currently the `Box<T>` type is special-cased and converted to the old
 `~T` internally. This is mostly invisible to the user, but it shows up
 in some places that give special treatment to `Box<T>`. This RFC is
 specifically concerned with the fact that the borrow checker has
-greater precision when derefencing `Box<T>` vs other smart pointers
+greater precision when dereferencing `Box<T>` vs other smart pointers
 that rely on the `Deref` traits. Unlike the other kinds of special
 treatment, we do not currently have a plan for how to extend this
 behavior to all smart pointer types, and hence we would like to remove
@@ -103,7 +103,7 @@ treatment of box to other smart pointer types:
    if the optimization is not performed it affects what programs can
    successfully type check. (Naturally it is also observable.)
 
-2. Some sort of unsafe deref trait that acknolwedges possibliity of
+2. Some sort of unsafe deref trait that acknowledges possibility of
    other pointers into the referent. Unappealing because the problem
    is not that bad as to require unsafety.
 

text/0132-ufcs.md

@@ -173,11 +173,11 @@ rejection are listed:
 
     module::type::(Trait::member)    <module::type as Trait>::member
     --> semantics of parentheses considered too subtle
-    --> cannot accomodate types that are not paths, like `[int]`
+    --> cannot accommodate types that are not paths, like `[int]`
 
     (type: Trait)::member            <type as Trait>::member
     --> complicated to parse
-    --> cannot accomodate types that are not paths, like `[int]`
+    --> cannot accommodate types that are not paths, like `[int]`
 
     ... (I can't remember all the rest)
 
@@ -209,4 +209,4 @@ to try and change the question:
   object type and then `ToStr` could be used as syntactic sugar for a
   type parameter.  But there exists a lot of precedent for the current
   approach and hence I think this is likely a bad idea (not to mention
-  that it'a a drastic change).
+  that it's a drastic change).

text/0135-where.md

@@ -444,7 +444,7 @@ This is unfortunately somewhat ambiguous, since a bound like `T:Eq`
 could either be declared a type parameter `T` or as a condition that
 the (existing) type `T` implement `Eq`.
 
-**Use a colon intead of the keyword.** There is some precedent for
+**Use a colon instead of the keyword.** There is some precedent for
 this from the type state days. Unfortunately, it doesn't work with
 traits due to the supertrait list, and it also doesn't look good with
 the use of `:` as a trait-bound separator:

text/0169-use-path-as-id.md

@@ -44,7 +44,7 @@ mod new_code {
 There are two benefits we can see by comparing `mod old_code` and `mod
 new_code`:
 
- * As alluded to above, now all of the imported identfifiers are on
+ * As alluded to above, now all of the imported identifiers are on
    the right-hand side of the block of view items.
 
  * Additionally, the left-hand side looks much more regular, since one
@@ -194,7 +194,7 @@ extern crate old_name as new_name;
 ```
 
 I have no opinion on whether this should be added or not.  Arguably
-this choice is orthgonal to the goals of this RFC (since, if this is a
+this choice is orthogonal to the goals of this RFC (since, if this is a
 good idea, it could just as well be implemented with the `=` syntax).
 Perhaps it should just be filed as a separate RFC on its own.
 

text/0212-restore-int-fallback.md

@@ -125,7 +125,7 @@ the major calling conventions), it's faster than 64-bit integers in
 arithmetic today, and is superior in memory usage while still providing
 a reasonable range of possible values.
 
-To expand on the perfomance argument: `i32` obviously uses half of the
+To expand on the performance argument: `i32` obviously uses half of the
 memory of `i64` meaning half the memory bandwidth used, half as much
 cache consumption and twice as much vectorization – additionally
 arithmetic (like multiplication and division) is faster on some of the

text/0213-defaulted-type-params.md

@@ -252,7 +252,7 @@ can only be referenced from within a fn body.
 ### References to generic impls
 
 Users never explicitly "reference" an impl. Rather, the trait matching
-system implicitly instantaites impls as part of trait matching. This
+system implicitly instantiates impls as part of trait matching. This
 implies that all type parameters are always instantiated with type
 variables. These type variables are assigned fallbacks according to
 the defaults given.

text/0235-collections-conventions.md

@@ -1367,7 +1367,7 @@ fn partitioned(&self, f: |&T| -> bool) -> (Vec<T>, Vec<T>);
 These two functions transform a vector/slice into a pair of vectors, based on a
 "partitioning" function that says which of the two vectors to place elements
 into. The `partition` variant works by moving elements of the vector, while
-`paritioned` clones elements.
+`partitioned` clones elements.
 
 There are a few unfortunate aspects of an API like this one:
 

text/0243-trait-based-exception-handling.md

@@ -122,7 +122,7 @@ associated block. If no exception is thrown, then the result is
 `Ok(v)` where `v` is the value of the block. Otherwise, if an
 exception is thrown, then the result is `Err(e)`. Note that unlike
 other languages, a `catch` block always catches all errors, and they
-must all be coercable to a single type, as a `Result` only has a
+must all be coercible to a single type, as a `Result` only has a
 single `Err` type. This dramatically simplifies thinking about the
 behavior of exception-handling code.
 
@@ -262,7 +262,7 @@ a distinct motivation, and we should evaluate them independently.
 
 # Unresolved questions
 
-These questions should be satisfactorally resolved before stabilizing the
+These questions should be satisfactorily resolved before stabilizing the
 relevant features, at the latest.
 
 ## Optional `match` sugar

text/0339-statically-sized-literals.md

@@ -162,7 +162,7 @@ Minor breakage:
 fn main() {
     let s = "Hello";
     fn f(arg: &str) {}
-    f(s); // Will require explicit slicing f(s[]) or implicit DST coersion from reference f(&s)
+    f(s); // Will require explicit slicing f(s[]) or implicit DST coercion from reference f(&s)
 }
 ```
 

text/0344-conventions-galore.md

@@ -265,7 +265,7 @@ easy to draw the wrong conclusion.
 This RFC proposes to use a `Prelude` suffix for these basic traits. Since the
 traits are, in fact, included in the prelude their names do not generally appear
 in Rust programs. Therefore, choosing a longer and clearer name will help avoid
-confusion about the intent of these traits, and will avoid namespace polution.
+confusion about the intent of these traits, and will avoid namespace pollution.
 
 (There is one important drawback in today's Rust: associated functions in these
 traits cannot yet be called directly on the types implementing the traits. These

text/0369-num-reform.md

@@ -6,7 +6,7 @@
 
 This RFC is preparation for API stabilization for the `std::num` module.  The
 proposal is to finish the simplification efforts started in
-[@bjz's reversal of the numerics hierarcy](https://github.com/rust-lang/rust/issues/10387).
+[@bjz's reversal of the numerics hierarchy](https://github.com/rust-lang/rust/issues/10387).
 
 Broadly, the proposal is to collapse the remaining numeric hierarchy
 in `std::num`, and to provide only limited support for generic
@@ -45,7 +45,7 @@ building such a hierarchy within `libstd` was misguided:
 The `std::num` module has thus been slowly migrating *away* from a large trait
 hierarchy toward a simpler one providing just APIs for primitive data types:
 this is
-[@bjz's reversal of the numerics hierarcy](https://github.com/rust-lang/rust/issues/10387).
+[@bjz's reversal of the numerics hierarchy](https://github.com/rust-lang/rust/issues/10387).
 
 Along side this effort, there are already external numerics packages like
 [@bjz's num-rs](https://github.com/bjz/num-rs).
@@ -233,7 +233,7 @@ pub trait Int: Copy + Clone + PartialOrd + PartialEq
     // Deprecated:
     // fn is_zero(&self) -> bool;
 
-    // Bit twidling
+    // Bit twiddling
     fn count_ones(self) -> uint;
     fn count_zeros(self) -> uint { ... }
     fn leading_zeros(self) -> uint;

text/0380-stabilize-std-fmt.md

@@ -224,7 +224,7 @@ some form of "write error" happened, but conveys no extra information.
 This API has a number of oddities:
 
 * The type `Formatter` has inherent `write` and `write_fmt` methods to be used
-  in conjuction with the `write!` macro return an instance of `fmt::Result`.
+  in conjunction with the `write!` macro return an instance of `fmt::Result`.
 * The `Formatter` type also implements the `std::io::Writer` trait in order to
   be able to pass around a `&mut Writer`.
 * This relies on the duck-typing of macros and for the inherent `write_fmt`

text/0385-module-system-cleanup.md

@@ -90,7 +90,7 @@ mod foo {
 
 ```
 
-While its generally not neccessary to export a extern library directly, the need for it does arise
+While its generally not necessary to export a extern library directly, the need for it does arise
 occasionally during refactorings of huge crate collections,
 generally if a public module gets turned into its own crate.
 

text/0390-enum-namespacing.md

@@ -245,7 +245,7 @@ bootstrapping.
 After a new stage 0 snapshot, the standard library will be ported and resolve
 will be updated to remove variant definitions in the flat namespace. This will
 happen as one atomic PR to keep the implementation phase as compressed as
-possible. In addition, if unforseen problems arise during this set of work, we
+possible. In addition, if unforeseen problems arise during this set of work, we
 can roll back the initial commit and put the change off until after 1.0, with
 only a small pre-1.0 change required. This initial conversion will focus on
 making the minimal set of changes required to port the compiler and standard
@@ -306,7 +306,7 @@ decidedly worse than not having to worry about fallback at all.
 
 Earlier iterations of namespaced enum proposals suggested preserving flat enums
 and adding `enum mod` syntax for namespaced enums. However, variant namespacing
-isn't a large enough enough difference for the additon of a second way to
+isn't a large enough enough difference for the addition of a second way to
 define enums to hold its own weight as a language feature. In addition, it
 would simply cause confusion, as library authors need to decide which one they
 want to use, and library consumers need to double check which place they can

text/0403-cargo-build-command.md

@@ -167,7 +167,7 @@ It is illegal to define `links` without also defining `build`.
 A number of native dependencies have various dependencies depending on what
 platform they're building for. For example, libcurl does not depend on OpenSSL
 on Windows, but it is a common dependency on unix-based systems. To this end,
-Cargo will gain support for platform-specific dependencies, solving constriant 7
+Cargo will gain support for platform-specific dependencies, solving constraint 7
 above:
 
 ```toml
@@ -258,7 +258,7 @@ separate set of dependencies solves a number of constraints:
 
 * When cross-compiling, the build tool as well as all of its dependencies are
   required to be built for the host architecture instead of the target
-  architecture. A clear deliniation will indicate precisely what dependencies
+  architecture. A clear delineation will indicate precisely what dependencies
   need to be built for the host architecture.
 * Common packages, such as one to build `cmake`-based dependencies, can develop
   conventions around filesystem hierarchy formats to require minimum