Merge pull request #1037 from kklibo/fix_typos

Fix typos + grammar

Author: ehuss

src/destructors.md

@@ -1,7 +1,7 @@
 # Destructors
 
 When an [initialized] [variable] or [temporary] goes out of
-[scope](#drop-scopes) its *destructor* is run, or it is *dropped*. [Assignment]
+[scope](#drop-scopes), its *destructor* is run, or it is *dropped*. [Assignment]
 also runs the destructor of its left-hand operand, if it's initialized. If a
 variable has been partially initialized, only its initialized fields are
 dropped.
@@ -154,7 +154,7 @@ temporary variable that holds the result of that expression when used in a
 [place context], unless it is [promoted].
 
 Apart from lifetime extension, the temporary scope of an expression is the
-smallest scope that contains the expression and is for one of the following:
+smallest scope that contains the expression and is one of the following:
 
 * The entire function body.
 * A statement.
@@ -246,7 +246,8 @@ loop {
 ### Constant promotion
 
 Promotion of a value expression to a `'static` slot occurs when the expression
-could be written in a constant, borrowed, and dereferencing that borrow where
+could be written in a constant and borrowed, and that borrow could be dereferenced
+where
 the expression was originally written, without changing the runtime behavior.
 That is, the promoted expression can be evaluated at compile-time and the
 resulting value does not contain [interior mutability] or [destructors] (these

src/dynamically-sized-types.md

@@ -18,7 +18,7 @@ types">DSTs</abbr>. Such types can only be used in certain cases:
   types">DSTs</abbr>.
   Unlike with generic type parameters, `Self: ?Sized` is the default in trait definitions.
 * Structs may contain a <abbr title="dynamically sized type">DST</abbr> as the
-  last field, this makes the struct itself a
+  last field; this makes the struct itself a
   <abbr title="dynamically sized type">DST</abbr>.
 
 > **Note**: [variables], function parameters, [const] items, and [static] items must be

src/expressions.md

@@ -179,11 +179,11 @@ move the value. Only the following place expressions may be moved out of:
 * [Variables] which are not currently borrowed.
 * [Temporary values](#temporaries).
 * [Fields][field] of a place expression which can be moved out of and
-  doesn't implement [`Drop`].
+  don't implement [`Drop`].
 * The result of [dereferencing][deref] an expression with type [`Box<T>`] and
   that can also be moved out of.
 
-When moving out of a place expression that evaluates to a local variable, the
+After moving out of a place expression that evaluates to a local variable, the
 location is deinitialized and cannot be read from again until it is
 reinitialized. In all other cases, trying to use a place expression in a value
 expression context is an error.

src/expressions/loop-expr.md

@@ -148,7 +148,7 @@ for n in 1..11 {
 assert_eq!(sum, 55);
 ```
 
-A for loop is equivalent to the following block expression.
+A `for` loop is equivalent to a `loop` expression containing a [`match` expression] as follows:
 
 <!-- ignore: expansion example -->
 ```rust,ignore

src/expressions/method-call-expr.md

@@ -71,7 +71,7 @@ These cases require a [disambiguating function call syntax] for method and funct
 ***Warning:*** For [trait objects], if there is an inherent method of the same name as a trait method, it will give a compiler error when trying to call the method in a method call expression.
 Instead, you can call the method using [disambiguating function call syntax], in which case it calls the trait method, not the inherent method.
 There is no way to call the inherent method.
-Just don't define inherent methods on trait objects with the same name a trait method and you'll be fine.
+Just don't define inherent methods on trait objects with the same name as a trait method and you'll be fine.
 
 </div>
 

src/glossary.md

@@ -125,7 +125,7 @@ implementation.
 
 A variable is initialized if it has been assigned a value and hasn't since been
 moved from. All other memory locations are assumed to be uninitialized. Only
-unsafe Rust can create such a memory without initializing it.
+unsafe Rust can create a memory location without initializing it.
 
 ### Local trait
 

src/items/extern-crates.md

@@ -64,7 +64,7 @@ by using an underscore with the form `extern crate foo as _`. This may be
 useful for crates that only need to be linked, but are never referenced, and
 will avoid being reported as unused.
 
-The [`macro_use` attribute] works as usual and import the macro names
+The [`macro_use` attribute] works as usual and imports the macro names
 into the [`macro_use` prelude].
 
 ## The `no_link` attribute

src/items/external-blocks.md

@@ -17,7 +17,7 @@ External blocks provide _declarations_ of items that are not _defined_ in the
 current crate and are the basis of Rust's foreign function interface. These are
 akin to unchecked imports.
 
-Two kind of item _declarations_ are allowed in external blocks: [functions] and
+Two kinds of item _declarations_ are allowed in external blocks: [functions] and
 [statics]. Calling functions or accessing statics that are declared in external
 blocks is only allowed in an `unsafe` context.
 

src/items/functions.md

@@ -74,7 +74,7 @@ If the first parameter is a _SelfParam_, this indicates that the function is a
 function] in a [trait] or [implementation].
 
 A parameter with the `...` token indicates a [variadic function], and may only
-be used as the last parameter of a [external block] function. The variadic
+be used as the last parameter of an [external block] function. The variadic
 parameter may have an optional identifier, such as `args: ...`.
 
 ## Function body

src/items/implementations.md

@@ -87,8 +87,8 @@ fn main() {
 ## Trait Implementations
 
 A _trait implementation_ is defined like an inherent implementation except that
-the optional generic type declarations is followed by a [trait] followed
-by the keyword `for`. Followed by a path to a nominal type.
+the optional generic type declarations are followed by a [trait], followed
+by the keyword `for`, followed by a path to a nominal type.
 
 <!-- To understand this, you have to back-reference to the previous section. :( -->
 
@@ -265,7 +265,7 @@ impl<'a> HasAssocType for Struct {
 
 Implementations may contain outer [attributes] before the `impl` keyword and
 inner [attributes] inside the brackets that contain the associated items. Inner
-attributes must come before any associated items. That attributes that have
+attributes must come before any associated items. The attributes that have
 meaning here are [`cfg`], [`deprecated`], [`doc`], and [the lint check
 attributes].
 

src/items/modules.md

@@ -65,7 +65,7 @@ contents in a file named `mod.rs` within that directory. The above example can
 alternately be expressed with `crate::util`'s contents in a file named
 `util/mod.rs`. It is not allowed to have both `util.rs` and `util/mod.rs`.
 
-> **Note**: Previous to `rustc` 1.30, using `mod.rs` files was the way to load
+> **Note**: Prior to `rustc` 1.30, using `mod.rs` files was the way to load
 > a module with nested children. It is encouraged to use the new naming
 > convention as it is more consistent, and avoids having many files named
 > `mod.rs` within a project.

src/lifetime-elision.md

@@ -103,7 +103,7 @@ If neither of those rules apply, then the bounds on the trait are used:
 // For the following trait...
 trait Foo { }
 
-// These two are the same as Box<T> has no lifetime bound on T
+// These two are the same because Box<T> has no lifetime bound on T
 type T1 = Box<dyn Foo>;
 type T2 = Box<dyn Foo + 'static>;
 

src/names/preludes.md

@@ -3,7 +3,7 @@
 A *prelude* is a collection of names that are automatically brought into scope
 of every module in a crate.
 
-These prelude names are not part of the module itself, they are implicitly
+These prelude names are not part of the module itself: they are implicitly
 queried during [name resolution]. For example, even though something like
 [`Box`] is in scope in every module, you cannot refer to it as `self::Box`
 because it is not a member of the current module.

src/types/closure.md

@@ -106,7 +106,7 @@ let z = &x;
 
 In this case, borrowing `x` mutably is not possible, because `x` is not `mut`.
 But at the same time, borrowing `x` immutably would make the assignment illegal,
-because a `& &mut` reference may not be unique, so it cannot safely be used to
+because a `& &mut` reference might not be unique, so it cannot safely be used to
 modify a value. So a unique immutable borrow is used: it borrows `x` immutably,
 but like a mutable borrow, it must be unique. In the above example, uncommenting
 the declaration of `y` will produce an error because it would violate the

src/types/slice.md

@@ -7,13 +7,12 @@
 A slice is a [dynamically sized type] representing a 'view' into a sequence of
 elements of type `T`. The slice type is written as `[T]`.
 
-To use a slice type it generally has to be used behind a pointer for example
-as:
+Slice types are generally used through pointer types. For example:
 
-* `&[T]`, a 'shared slice', often just called a 'slice', it doesn't own the
-  data it points to, it borrows it.
-* `&mut [T]`, a 'mutable slice', mutably borrows the data it points to.
-* `Box<[T]>`, a 'boxed slice'
+* `&[T]`: a 'shared slice', often just called a 'slice'. It doesn't own the
+  data it points to; it borrows it.
+* `&mut [T]`: a 'mutable slice'. It mutably borrows the data it points to.
+* `Box<[T]>`: a 'boxed slice'
 
 Examples: