Fix typos in RFCs 501-750

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