Fix typos in RFCs 2501-2750

Author: jhpratt

text/2514-union-initialization-and-drop.md

@@ -193,7 +193,7 @@ union U<T> { x:(), f: ManuallyDrop<T> }
 
 fn main() {
     let mut u : U<(Vec<i32>,)> = U { x: () };
-    unsafe { u.f.0 = Vec::new() }; // uninitialized `Vec` being droped
+    unsafe { u.f.0 = Vec::new() }; // uninitialized `Vec` being dropped
 }
 ```
 This requires `unsafe` because it desugars to `ManuallyDrop::deref_mut(&mut u.f).0`,

text/2515-type_alias_impl_trait.md

@@ -52,7 +52,7 @@ fn foo() -> __foo_return {
 }
 ```
 
-The generated type `__foo_return` is not exposed: it is automatically contructed from any valid type (as in `(3)`).
+The generated type `__foo_return` is not exposed: it is automatically constructed from any valid type (as in `(3)`).
 
 Note that, in order for the type inference to support argument-position `impl Trait`, which may be polymorphic (just like a generic parameter), the inference used here is actually a more expressive form of type inference similar to ML-style let polymorphism. Here, the inference of function types may result in additional generic parameters, specifically relating to the occurrences of argument-position `impl Trait`.
 
@@ -96,7 +96,7 @@ fn foo() -> Baz {
 }
 ```
 
-However, if the function is parameterised, it may be necessary to add explicit parameters to the type alias (due to the return-type being within the scope of the function's generic paramters, unlike the type alias).
+However, if the function is parameterised, it may be necessary to add explicit parameters to the type alias (due to the return-type being within the scope of the function's generic parameters, unlike the type alias).
 
 Using `Baz` in multiple locations constrains all occurrences of the inferred type to be the same, just as with `existential type`.
 

text/2521-c_void-reunification.md

@@ -80,7 +80,7 @@ A pointer returned from one library can now be passed to the other library witho
 In the standard library:
 
 * Create a new `core::ffi` module.
-* Move the `enum` definiton of `c_void` there.
+* Move the `enum` definition of `c_void` there.
 * In `c_void`’s former location (`std::os::raw`), replace it with a `pub use` reexport.
 * For consistency between `core` and `std`, also add a similar `pub use` reexport at `std::ffi::c_void`.
   (Note that the `std::ffi` module already exists.)
@@ -91,7 +91,7 @@ Once the above lands in Nightly, in the `libc` crate:
   (for example by executing `$RUSTC` with a temporary file like
   `#![crate_type = "lib"] #![no_std] pub use core::ffi::c_void;`)
   and conditionally set a compilation flag for the library.
-* In the library, based on the precence of that flag,
+* In the library, based on the presence of that flag,
   make `c_void` be either `pub use core::ffi::c_void;` or its current `enum` definition,
   to keep compatibility with older Rust versions.
 
@@ -147,7 +147,7 @@ for example, `ptr::null::<c_void>()` and `<*mut c_void>::offset(n)` would not be
 
 We could deprecated `c_void` and replace it with a new differently-named extern type,
 but forcing the ecosystem through that transition seems too costly for this theoretical nicety.
-Plus, this woud still be a nominal type.
+Plus, this would still be a nominal type.
 If this new type is to be present if both `libc` and `std`,
  it would still have to be in `core` as well.
 
@@ -176,5 +176,5 @@ This is left for a future RFC.
 This RFC does not propose any change such as moving to libcore for the C types other than `c_void`.
 
 Although some in previous discussions have expressed desire for using C-compatible types
-without linking to the C runtime libray (which the `libc` crate does) or depending on `std`.
+without linking to the C runtime library (which the `libc` crate does) or depending on `std`.
 This use case is also left for a future proposal or RFC.

text/2526-const-wildcard.md

@@ -19,7 +19,7 @@ compile if the type `MyType` doesn't implement the trait `MyTrait`:
 ```rust
 const _FOO: () = {
     use std::marker::PhantomData;
-    struct ImpelementsMyTrait<T: MyTrait>(PhantomData<T>);
+    struct ImplementsMyTrait<T: MyTrait>(PhantomData<T>);
     let _ = ImplementsMyTrait::<MyType>(PhantomData); // type checking error if MyType: !MyTrait
     ()
 };

text/2532-associated-type-defaults.md

@@ -976,7 +976,7 @@ associated type include:
            type Output = Self;
 
            // OK to assume what `Output` really is because any overriding
-           // must override both `Outout` and `finish`.
+           // must override both `Output` and `finish`.
            fn finish(self) -> Self::Output { self }
        }
    }
@@ -1403,7 +1403,7 @@ impl Bar for Theta {
 
 impl Bar for Iota {
     // We have overridden `Bar` which is in the root group.
-    // Since all other items are decendants of the same group as `Bar` is in,
+    // Since all other items are descendants of the same group as `Bar` is in,
     // they are allowed to depend on what `Bar` is.
     type Bar = u8;
 

text/2535-or-patterns.md

@@ -527,7 +527,7 @@ param : pat<no_top_alt> ':' ty_sum ;
 For closures we now have:
 
 ```rust
-inferrable_param : pat<no_top_alt> maybe_ty_ascription ;
+inferable_param : pat<no_top_alt> maybe_ty_ascription ;
 ```
 
 Finally, `pat` macro fragment specifiers will also match the `pat<no_top_alt>`
@@ -851,7 +851,7 @@ There is support for or-patterns in [various lisp libraries][lisp_libs].
 # Unresolved questions
 [unresolved]: #unresolved-questions
 
-1. Should we allow `top_pat` or `pat<allow_top_alt>` in `inferrable_param` such
+1. Should we allow `top_pat` or `pat<allow_top_alt>` in `inferable_param` such
    that closures permit `|Ok(x) | Err(x)|` without first wrapping in parenthesis?
 
    We defer this decision to stabilization as it may depend on experimentation.

text/2539-cfg_attr-multiple-attrs.md

@@ -30,7 +30,7 @@ For an example of multiple attributes, say we want to have two attribute macros
 (`sparkles` and `crackles`), but only when `feature = "magic"` is enabled. We
 can write this as:
 
-```rust,igore
+```rust,ignore
 #[cfg_attr(feature = "magic", sparkles, crackles)]
 fn bewitched() {}
 ```
@@ -86,7 +86,7 @@ mod os;
 For an example of multiple attributes, say we want to have two attribute macros,
 but only when `feature = "magic"` is enabled. We can write this as:
 
-```rust,igore
+```rust,ignore
 #[cfg_attr(feature = "magic", sparkles, crackles)]
 fn bewitched() {}
 ```
@@ -122,7 +122,7 @@ Today, an attribute can look like:
 * ``name = `TokenTree` ``
 
 where `TokenStream` is a sequence of tokens that only has the restriction that
-delimiters match and `TokenTree` is a single identifer, literal, punctuation
+delimiters match and `TokenTree` is a single identifier, literal, punctuation
 mark, or a delimited `TokenStream`.
 
 With this RFC accepted, the following cannot ever be parsed as attributes:

text/2580-ptr-meta.md

@@ -31,7 +31,7 @@ from the standard library.
 as it was guaranteed to have the same memory layout.
 This was replaced with more specific and less wildly unsafe
 `std::slice::from_raw_parts` and `std::slice::from_raw_parts_mut` functions,
-together with `as_ptr` and `len` methods that extract each fat pointer component separatly.
+together with `as_ptr` and `len` methods that extract each fat pointer component separately.
 
 For trait objects, where we still have an unstable `std::raw::TraitObject` type
 that can only be used with `transmute`:
@@ -46,7 +46,7 @@ pub struct TraitObject {
 
 [`std::raw::Repr`]: https://doc.rust-lang.org/1.10.0/std/raw/trait.Repr.html
 [`std::raw::Slice`]: https://doc.rust-lang.org/1.10.0/std/raw/struct.Slice.html
-[`std::raw::TraitObjet`]: https://doc.rust-lang.org/1.30.0/std/raw/struct.TraitObject.html
+[`std::raw::TraitObject`]: https://doc.rust-lang.org/1.30.0/std/raw/struct.TraitObject.html
 
 
 # Motivation
@@ -100,7 +100,7 @@ struct WithMeta<T: ?Sized> {
 Since [unsized rvalues] are not implemented yet,
 our constructor is going to “unsize” from a concrete type that implements our trait.
 The `Unsize` bound ensures we can cast from `&S` to a `&Dyn` trait object
-and construct the appopriate metadata.
+and construct the appropriate metadata.
 
 [unsized rvalues]: https://github.com/rust-lang/rust/issues/48055
 
@@ -373,7 +373,7 @@ Except for `DynMetadata`’s methods, this RFC proposes a subset of what that th
   This might reduce monomorphization cost,
   but would force that the size, alignment, and destruction pointers
   be in the same location (offset) for every vtable.
-  But keeping them in the same location is probaly desirable anyway to keep code size small.
+  But keeping them in the same location is probably desirable anyway to keep code size small.
 
 * The name of `Thin`.
   This name is short and sweet but `T: Thin` suggests that `T` itself is thin,
@@ -385,7 +385,7 @@ Except for `DynMetadata`’s methods, this RFC proposes a subset of what that th
   Or could it ever make sense to have fat pointers to statically-sized types?
 
 * Are there other generic standard library APIs like `ptr::null()`
-  that have an (implicit) `T: Sized` bound that unneccesarily excludes extern types?
+  that have an (implicit) `T: Sized` bound that unnecessarily excludes extern types?
 
 * Should `<*mut _>::from_raw_parts` and friends be `unsafe fn`s?
 

text/2582-raw-reference-mir-operator.md

@@ -18,7 +18,7 @@ Currently, if one wants to create a raw pointer pointing to something, one has n
 The problem with this is that there are some invariants that we want to attach to references, that have to *always hold*.
 The details of this are not finally decided yet, but true in practice because of annotations we emit to LLVM.
 It is also the next topic of discussion in the [Unsafe Code Guidelines](https://github.com/rust-rfcs/unsafe-code-guidelines/).
-In particular, references must be aligned and dereferencable, even when they are created and never used.
+In particular, references must be aligned and dereferenceable, even when they are created and never used.
 
 One consequence of these rules is that it becomes essentially impossible to create a raw pointer pointing to an unaligned struct field:
 `&packed.field as *const _` creates an intermediate unaligned reference, triggering undefined behavior because it is not aligned.
@@ -63,7 +63,7 @@ let x = unsafe { &packed.field }; // `x` is not aligned -> undefined behavior
 ```
 
 There is no situation in which the above code is correct, and hence it is a hard error to write this (after a transition period).
-This applies to most ways of creating a reference, i.e., all of the following are UB if `X` is not properly aligned and dereferencable:
+This applies to most ways of creating a reference, i.e., all of the following are UB if `X` is not properly aligned and dereferenceable:
 
 ```rust
 fn foo() -> &T {

text/2591-exhaustive-integer-pattern-matching.md

@@ -67,7 +67,7 @@ The implementation of this features uses interval arithmetic and an extension of
 
 This feature has already [been implemented](https://github.com/rust-lang/rust/pull/50912), so the code there may be used for further reference. The source contains detailed comments about the implementation.
 
-For `usize` and `isize`, no assumptions about the maximimum value are permitted. To exhaustively match on either pointer-size integer type a wildcard pattern (`_`) must be used (or if [open-ended range patterns are added](https://github.com/rust-lang/rfcs/issues/947), ranges must be open ended [e.g. `0..`]). An unstable feature `precise_pointer_size_matching` will be added to permit matching exactly on pointer-size integer types.
+For `usize` and `isize`, no assumptions about the maximum value are permitted. To exhaustively match on either pointer-size integer type a wildcard pattern (`_`) must be used (or if [open-ended range patterns are added](https://github.com/rust-lang/rfcs/issues/947), ranges must be open ended [e.g. `0..`]). An unstable feature `precise_pointer_size_matching` will be added to permit matching exactly on pointer-size integer types.
 
 # Drawbacks
 [drawbacks]: #drawbacks