minor grammar and typo fixes

Author: kklibo

src/destructors.md

@@ -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/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.