Rollup merge of #45407 - topecongiro:fix-typos/librust-hir-README, r=kennytm

Fix typos in README.md

3 files changed, 8 insertions, 8 deletions

diff --git a/src/librustc/hir/README.md b/src/librustc/hir/README.md
index c832a897dee..e283fc40c50 100644
--- a/src/librustc/hir/README.md
+++ b/src/librustc/hir/README.md
@@ -57,7 +57,7 @@ carry around references into the HIR, but rather to carry around
 *identifier numbers* (or just "ids"). Right now, you will find four
 sorts of identifiers in active use:
 
-- `DefId`, which primarily name "definitions" or top-level items.
+- `DefId`, which primarily names "definitions" or top-level items.
   - You can think of a `DefId` as being shorthand for a very explicit
     and complete path, like `std::collections::HashMap`. However,
     these paths are able to name things that are not nameable in
@@ -114,6 +114,6 @@ A **body** represents some kind of executable code, such as the body
 of a function/closure or the definition of a constant. Bodies are
 associated with an **owner**, which is typically some kind of item
 (e.g., a `fn()` or `const`), but could also be a closure expression
-(e.g., `|x, y| x + y`). You can use the HIR map to find find the body
+(e.g., `|x, y| x + y`). You can use the HIR map to find the body
 associated with a given def-id (`maybe_body_owned_by()`) or to find
 the owner of a body (`body_owner_def_id()`).
diff --git a/src/librustc/mir/README.md b/src/librustc/mir/README.md
index e8ed8bf104c..fb0c7ce1df2 100644
--- a/src/librustc/mir/README.md
+++ b/src/librustc/mir/README.md
@@ -6,7 +6,7 @@ register and define new MIR transformations and analyses.
 
 Most of the code that operates on MIR can be found in the
 `librustc_mir` crate or other crates. The code found here in
-`librustc` is just the datatype definitions, alonging the functions
+`librustc` is just the datatype definitions, along with the functions
 which operate on MIR to be placed everywhere else.
 
 ## MIR Data Types and visitor
@@ -27,7 +27,7 @@ As a MIR *consumer*, you are expected to use one of the queries that
 returns a "final MIR". As of the time of this writing, there is only
 one: `optimized_mir(def_id)`, but more are expected to come in the
 future. For foreign def-ids, we simply read the MIR from the other
-crate's metadata. But for local query, this query will construct the
+crate's metadata. But for local def-ids, the query will construct the
 MIR and then iteratively optimize it by putting it through various
 pipeline stages. This section describes those pipeline stages and how
 you can extend them.
@@ -51,7 +51,7 @@ a `&'tcx Steal<Mir<'tcx>>`, allocated using
 **stolen** by the next suite of optimizations -- this is an
 optimization to avoid cloning the MIR. Attempting to use a stolen
 result will cause a panic in the compiler. Therefore, it is important
-that you not read directly from these intermediate queries except as
+that you do not read directly from these intermediate queries except as
 part of the MIR processing pipeline.
 
 Because of this stealing mechanism, some care must also be taken to
diff --git a/src/librustc/ty/maps/README.md b/src/librustc/ty/maps/README.md
index 8abc68d431a..8207c18e677 100644
--- a/src/librustc/ty/maps/README.md
+++ b/src/librustc/ty/maps/README.md
@@ -169,7 +169,7 @@ That is, they take an `&mut Providers` and mutate it in place. Usually
 we use the formulation above just because it looks nice, but you could
 as well do `providers.type_of = type_of`, which would be equivalent.
 (Here, `type_of` would be a top-level function, defined as we saw
-before.) So, if we wanted to have add a provider for some other query,
+before.) So, if we want to add a provider for some other query,
 let's call it `fubar`, into the crate above, we might modify the `provide()`
 function like so:
 
@@ -185,7 +185,7 @@ pub fn provide(providers: &mut Providers) {
 fn fubar<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx>, key: DefId) -> Fubar<'tcx> { .. }
 ```
 
-NB. Most of the `rustc_*` crate only provide **local
+NB. Most of the `rustc_*` crates only provide **local
 providers**. Almost all **extern providers** wind up going through the
 `rustc_metadata` crate, which loads the information from the crate
 metadata.  But in some cases there are crates that provide queries for
@@ -201,7 +201,7 @@ Well, defining a query takes place in two steps:
 1. first, you have to specify the query name and arguments; and then,
 2. you have to supply query providers where needed.
 
-The specify the query name and arguments, you simply add an entry
+To specify the query name and arguments, you simply add an entry
 to the big macro invocation in `mod.rs`. This will probably have changed
 by the time you read this README, but at present it looks something
 like: