Merge pull request #3277 from jhpratt/fix-typos

Fix typos

Author: ehuss

compiler_changes.md

@@ -28,7 +28,7 @@ submitted later if there is scope for large changes to the language RFC.
 * Adding, removing, or changing a stable compiler flag
 * The implementation of new language features where there is significant change
   or addition to the compiler. There is obviously some room for interpretation
-  about what consitutes a "significant" change and how much detail the
+  about what constitutes a "significant" change and how much detail the
   implementation RFC needs. For guidance, [associated items](text/0195-associated-items.md)
   and [UFCS](text/0132-ufcs.md) would clearly need an implementation RFC,
   [type ascription](text/0803-type-ascription.md) and
@@ -41,7 +41,7 @@ submitted later if there is scope for large changes to the language RFC.
 
 * Bug fixes, improved error messages, etc.
 * Minor refactoring/tidying up
-* Implmenting language features which have an accepted RFC, where the
+* Implementing language features which have an accepted RFC, where the
   implementation does not significantly change the compiler or require
   significant new design work
 * Adding unstable API for tools (note that all compiler API is currently unstable)

libs_changes.md

@@ -76,7 +76,7 @@ as `std` has become more conservative in favour of the much more agile cargovers
     * Too marginal for std
     * Significant implementation problems
 
-* A PR may also be closed because an RFC is approriate.
+* A PR may also be closed because an RFC is appropriate.
 
 * A (non-RFC) PR  may be **merged as unstable**. In this case, the feature
 should have a fresh feature gate and an associated tracking issue for

style-guide/expressions.md

@@ -643,7 +643,7 @@ Examples:
 ```rust
 match foo {
     foo => bar,
-    a_very_long_patten | another_pattern if an_expression() => {
+    a_very_long_pattern | another_pattern if an_expression() => {
         no_room_for_this_expression()
     }
     foo => {

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

@@ -71,8 +71,8 @@ opt-in. There are two main reasons for my concern:
 
 To elaborate on those two points: With respect to parallelization: for
 the most part, Rust types are threadsafe "by default". To make
-something non-threadsafe, you must employ unsychronized interior
-mutability (e.g., `Cell`, `RefCell`) or unsychronized shared ownership
+something non-threadsafe, you must employ unsynchronized interior
+mutability (e.g., `Cell`, `RefCell`) or unsynchronized shared ownership
 (`Rc`). In both cases, there are also synchronized variants available
 (`Mutex`, `Arc`, etc). This implies that we can make APIs to enable
 intra-task parallelism and they will work ubiquitously, so long as
@@ -116,7 +116,7 @@ All three of these (`Snapshot`, `NoManaged`, `NoDrop`) can be easily
 defined using traits with default impls.
 
 A final, somewhat weaker, motivator is aesthetics. Ownership has allowed
-us to move threading almost entirely into libaries. The one exception
+us to move threading almost entirely into libraries. The one exception
 is that the `Send` and `Share` types remain built-in. Opt-in traits
 makes them *less* built-in, but still requires custom logic in the
 "impl matching" code as well as special safety checks when

text/0040-libstd-facade.md

@@ -164,7 +164,7 @@ algorithms apart from the default sorting algorithm.
 #### FromStr
 
 This trait and module are left out because strings are left out. All types in
-libmini can have their implemention of FromStr in the crate which implements
+libmini can have their implementation of FromStr in the crate which implements
 strings
 
 #### Floats

text/0048-traits.md

@@ -231,7 +231,7 @@ Note that there is some interaction with the distinction between input
 and output type parameters discussed in the previous
 example. Specifically, we must never *infer* the value of the `Self`
 type parameter based on the impls in scope. This is because it would
-cause *crate concatentation* to potentially lead to compilation errors
+cause *crate concatenation* to potentially lead to compilation errors
 in the form of inference failure.
 
 ## Properties
@@ -242,7 +242,7 @@ There are important properties I would like to guarantee:
   values for all of its type parameters, there should always be at
   most one applicable impl. This should remain true even when unknown,
   additional crates are loaded.
-- **Crate concatentation:** It should always be possible to take two
+- **Crate concatenation:** It should always be possible to take two
   creates and combine them without causing compilation errors. This
   property
 

text/0155-anonymous-impl-only-in-same-module.md

@@ -101,7 +101,7 @@ and methods of a struct should be defined nearby.
 I propose three changes to the language:
 
 - `impl` on multiple-ident paths such as `impl mymod::MyStruct` is disallowed.
-  Since this currently suprises the user by having absolutely no effect for
+  Since this currently surprises the user by having absolutely no effect for
   static methods, support for this is already broken.
 - `impl MyStruct` must occur in the same module that `MyStruct` is defined.
   This is to prevent the above problems with `impl`-across-modules.

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

@@ -5,7 +5,7 @@
 # Summary
 
 Change the rebinding syntax from `use ID = PATH` to `use PATH as ID`,
-so that paths all line up on the left side, and imported identifers
+so that paths all line up on the left side, and imported identifiers
 are all on the right side.  Also modify `extern crate` syntax
 analogously, for consistency.
 

text/0194-cfg-syntax.md

@@ -85,7 +85,7 @@ proposed names read better with the function-like syntax and are consistent
 with `Iterator::all` and `Iterator::any`.
 
 Issue [#2119](https://github.com/rust-lang/rust/issues/2119) proposed the
-addition of `||` and `&&` operators and parantheses to the attribute syntax
+addition of `||` and `&&` operators and parentheses to the attribute syntax
 to result in something like `#[cfg(a || (b && c)]`. I don't favor this proposal
 since it would result in a major change to the attribute syntax for relatively
 little readability gain.

text/0195-associated-items.md

@@ -1263,7 +1263,7 @@ impl<'a, T> Sliceable for &'a Vec<T> {
 But then there's a difficult question:
 
 ```
-fn dice<A>(a: &A) -> &A::Slice where &A: Slicable {
+fn dice<A>(a: &A) -> &A::Slice where &A: Sliceable {
     a // is this allowed?
 }
 ```

text/0218-empty-struct-with-braces.md

@@ -98,7 +98,7 @@ completed, one can then take the next step of adding the actual field.
 # Drawbacks
 
 Some people like "There is only one way to do it."  But, there is
-precendent in Rust for violating "one way to do it" in favor of
+precedent in Rust for violating "one way to do it" in favor of
 syntactic convenience or regularity; see
 the [Precedent for flexible syntax in Rust] appendix.
 Also, see the [Always Require Braces] alternative below.
@@ -311,7 +311,7 @@ adoption of [Rust RFC 25].
 
 ## Precedent for flexible syntax in Rust
 
-There is precendent in Rust for violating "one way to do it" in favor
+There is precedent in Rust for violating "one way to do it" in favor
 of syntactic convenience or regularity.
 
 For example, one can often include an optional trailing comma, for
@@ -358,7 +358,7 @@ is not a democracy, the number of commenters should not matter anyway.)
 * "Frequently start out with an empty struct and add fields as I need them." ==> Favors: This RFC or Always Require Braces
 * "Foo{} suggests is constructing something that it's not; all uses of the value `Foo` are indistinguishable from each other" ==> Favors: Status Quo
 * "I find it strange anyone would prefer `let x = Foo{};` over `let x = Foo;`" ==> Favors Status Quo; strongly opposes Always Require Braces.
-* "I agree that 'instantiation-should-follow-declation', that is, structs declared `;, (), {}` should only be instantiated [via] `;, (), { }` respectively" ==> Opposes leniency of this RFC in that it allows expression to use include or omit `{}` on an empty struct, regardless of declaration form, and vice-versa.
+* "I agree that 'instantiation-should-follow-declaration', that is, structs declared `;, (), {}` should only be instantiated [via] `;, (), { }` respectively" ==> Opposes leniency of this RFC in that it allows expression to use include or omit `{}` on an empty struct, regardless of declaration form, and vice-versa.
 * "The code generation argument is reasonable, but I wouldn't want to force noisier syntax on all 'normal' code just to make macros work better." ==> Favors: This RFC
 
 [Always Require Braces]: #always-require-braces

text/0403-cargo-build-command.md

@@ -394,7 +394,7 @@ directly. Additionally, packages using `*-sys` packages should not declare a
 ## Phasing strategy
 
 The modifications to the `build` command are breaking changes to Cargo. To ease
-the transition, the build comand will be join'd to the root path of a crate, and
+the transition, the build command will be join'd to the root path of a crate, and
 if the file exists and ends with `.rs`, it will be compiled as describe above.
 Otherwise a warning will be printed and the fallback behavior will be
 executed.

text/0517-io-os-reform.md

@@ -1470,7 +1470,7 @@ Windows, it can be considered an optimization for `flush` and on
 Windows behave identically to `sync_all`, just as it does on some Unix
 filesystems.)
 
-The `path` method wil remain `#[unstable]`, as we do not yet want to
+The `path` method will remain `#[unstable]`, as we do not yet want to
 commit to its API.
 
 The `open_mode` function will be removed in favor of and will take an

text/0546-Self-not-sized-by-default.md

@@ -39,7 +39,7 @@ implemented):
 trait Foo for ?Sized { ... }
 ```
 
-This syntax doesn't have any other precendent in the language. One
+This syntax doesn't have any other precedent in the language. One
 might expect to write:
 
 ```rust

text/0550-macro-future-proofing.md

@@ -12,7 +12,7 @@ possible to lift these restrictions backwards compatibly if desired.
 
 # Key Terminology
 
-- `macro`: anything invokable as `foo!(...)` in source code.
+- `macro`: anything invocable as `foo!(...)` in source code.
 - `MBE`: macro-by-example, a macro defined by `macro_rules`.
 - `matcher`: the left-hand-side of a rule in a `macro_rules` invocation, or a subportion thereof.
 - `macro parser`: the bit of code in the Rust parser that will parse the input using a grammar derived from all of the matchers.
@@ -45,7 +45,7 @@ and `$foo` and `$i` are simple NT's with `expr` and `ident` as their
 respective fragment specifiers.
 
 `$(i:ident),*` is *also* an NT; it is a complex NT that matches a
-comma-seprated repetition of identifiers. The `,` is the separator
+comma-separated repetition of identifiers. The `,` is the separator
 token for the complex NT; it occurs in between each pair of elements
 (if any) of the matched fragment.
 
@@ -329,7 +329,7 @@ accordingly.
 
 Below are some examples of FIRST and LAST.
 (Note in particular how the special ε element is introduced and
-eliminated based on the interation between the pieces of the input.)
+eliminated based on the interaction between the pieces of the input.)
 
 Our first example is presented in a tree structure to elaborate on how
 the analysis of the matcher composes. (Some of the simpler subtrees

text/0599-default-object-bound.md

@@ -147,7 +147,7 @@ source today, but this has not been fully verified.)
 
 # Detailed design
 
-This section extends the high-level rule above with suppor for
+This section extends the high-level rule above with support for
 user-defined types, and also describes potential interactions with
 other parts of the system.
 
@@ -243,7 +243,7 @@ the expansion of `Box<SomeTrait>` would be different.
 
 **Interaction with object coercion.** The rules specify that `&'a
 SomeTrait` and `&'a mut SomeTrait` are expanded to `&'a
-(SomeTrait+'a)`and `&'a mut (SomeTrait+'a)` respecively. Today, in fn
+(SomeTrait+'a)`and `&'a mut (SomeTrait+'a)` respectively. Today, in fn
 signatures, one would get the expansions `&'a (SomeTrait+'b)` and `&'a
 mut (SomeTrait+'b)`, respectively. In the case of a shared reference
 `&'a SomeTrait`, this difference is basically irrelevant, as the

text/0639-discriminant-intrinsic.md

@@ -93,7 +93,7 @@ Note the returned values for two differently-typed variants may compare in any w
   simply treat them as single-variant enums and synthesise a zero constant. Note that this is what
   would be done for single-variant enums anyway.
 
-* Do nothing. Improvements to codegen and/or optimisation could make this uneccessary. The
+* Do nothing. Improvements to codegen and/or optimisation could make this unnecessary. The
   "Sufficiently Smart Compiler" trap is a strong case against this reasoning though. There will
   likely always be cases where the user can write more efficient code than the compiler can produce.
 
@@ -329,7 +329,7 @@ pub enum SqlState {
     FdwReplyHandle,
     FdwSchemaNotFound,
     FdwTableNotFound,
-    FdwUnableToCreateExcecution,
+    FdwUnableToCreateExecution,
     FdwUnableToCreateReply,
     FdwUnableToEstablishConnection,
     PlpgsqlError,

text/0738-variance.md

@@ -86,7 +86,7 @@ Here the `Context` struct has one lifetime parameter, `data`, that
 represents the lifetime of some data that it references. Now let's
 imagine that the lifetime of the data is some lifetime we call
 `'x`. If we have a context `cx` of type `Context<'x>`, it is ok to
-(for example) pass `cx` as an argment where a value of type
+(for example) pass `cx` as an argument where a value of type
 `Context<'y>` is required, so long as `'x : 'y` ("`'x` outlives
 `'y`"). That is, it is ok to approximate `'x` as a shorter lifetime
 like `'y`. This makes sense because by changing `'x` to `'y`, we're
@@ -199,7 +199,7 @@ used in the body of the type. This generally occurs with unsafe code:
 
 Since these parameters are unused, the inference can reasonably
 conclude that `AtomicPtr<int>` and `AtomicPtr<uint>` are
-interchangable: after all, there are no fields of type `T`, so what
+interchangeable: after all, there are no fields of type `T`, so what
 difference does it make what value it has? This is not good (and in
 fact we have behavior like this today for lifetimes, which is a common
 source of error).

text/0769-sound-generic-drop.md

@@ -4,7 +4,7 @@
 
 # History
 
-2015.09.18 -- This RFC was partially superceded by [RFC 1238], which
+2015.09.18 -- This RFC was partially superseded by [RFC 1238], which
 removed the parametricity-based reasoning in favor of an attribute.
 
 [RFC 1238]: https://github.com/rust-lang/rfcs/blob/master/text/1238-nonparametric-dropck.md

text/0953-op-assign.md

@@ -42,7 +42,7 @@ Implement these traits for the primitive numeric types *without* overloading,
 i.e. only `impl AddAssign<i32> for i32 { .. }`.
 
 Add an `op_assign` feature gate. When the feature gate is enabled, the compiler
-will consider these traits when typecheking `a += b`. Without the feature gate
+will consider these traits when typechecking `a += b`. Without the feature gate
 the compiler will enforce that `a` and `b` must be primitives of the same
 type/category as it does today.
 

text/0980-read-exact.md

@@ -56,7 +56,7 @@ The following method is added to the `Read` trait:
 fn read_exact(&mut self, buf: &mut [u8]) -> Result<()>;
 ```
 
-Aditionally, a default implementation of this method is provided:
+Additionally, a default implementation of this method is provided:
 
 ``` rust
 fn read_exact(&mut self, mut buf: &mut [u8]) -> Result<()> {

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

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.)

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

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

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

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.

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