Changed all instances of `e.g.,` to `e.g.`, and similar.

CODE_OF_CONDUCT.md

@@ -23,8 +23,8 @@ These are the policies for upholding our community's standards of conduct. If yo
 1. Remarks that violate the Rust standards of conduct, including hateful, hurtful, oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but never targeting another user, and never in a hateful manner.)
 2. Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed.
 3. Moderators will first respond to such remarks with a warning.
-4. If the warning is unheeded, the user will be "kicked," i.e., kicked out of the communication channel to cool off.
-5. If the user comes back and continues to make trouble, they will be banned, i.e., indefinitely excluded.
+4. If the warning is unheeded, the user will be "kicked," i.e. kicked out of the communication channel to cool off.
+5. If the user comes back and continues to make trouble, they will be banned, i.e. indefinitely excluded.
 6. Moderators may choose at their discretion to un-ban the user if it was a first offense and they offer the offended party a genuine apology.
 7. If a moderator bans someone and you think it was unjustified, please take it up with that moderator, or with a different moderator, **in private**. Complaints about bans in-channel are not allowed.
 8. Moderators are held to a higher standard than other community members. If a moderator creates an inappropriate situation, they should expect less leeway than others.

src/glossary.md

@@ -25,7 +25,7 @@ provider                |  the function that executes a query ([see more](query.
 sess                    |  the compiler session, which stores global data used throughout compilation
 side tables             |  because the AST and HIR are immutable once created, we often carry extra information about them in the form of hashtables, indexed by the id of a particular node.
 span                    |  a location in the user's source code, used for error reporting primarily. These are like a file-name/line-number/column tuple on steroids: they carry a start/end point, and also track macro expansions and compiler desugaring. All while being packed into a few bytes (really, it's an index into a table). See the Span datatype for more.
-substs                  |  the substitutions for a given generic type or item (e.g., the `i32`, `u32` in `HashMap<i32, u32>`)
+substs                  |  the substitutions for a given generic type or item (e.g. the `i32`, `u32` in `HashMap<i32, u32>`)
 tcx                     |  the "typing context", main data structure of the compiler ([see more](ty.html))
 'tcx                    |  the lifetime of the currently active inference context ([see more](ty.html))
 trans                   |  the code to translate MIR into LLVM IR.

src/high-level-overview.md

@@ -48,7 +48,7 @@ more and more to the [query model], however, the
 
 At the other extreme, the `rustc` crate defines the common and
 pervasive data structures that all the rest of the compiler uses
-(e.g., how to represent types, traits, and the program itself). It
+(e.g. how to represent types, traits, and the program itself). It
 also contains some amount of the compiler itself, although that is
 relatively limited.
 
@@ -77,8 +77,8 @@ purely "pass-based" compiler, where we ran a number of passes over the
 entire program, and each did a particular check of transformation. We
 are gradually replacing this pass-based code with an alternative setup
 based on on-demand **queries**. In the query-model, we work backwards,
-executing a *query* that expresses our ultimate goal (e.g., "compile
-this crate"). This query in turn may make other queries (e.g., "get me
+executing a *query* that expresses our ultimate goal (e.g. "compile
+this crate"). This query in turn may make other queries (e.g. "get me
 a list of all modules in the crate"). Those queries make other queries
 that ultimately bottom out in the base operations, like parsing the
 input, running the type-checker, and so forth. This on-demand model

src/hir.md

@@ -18,7 +18,7 @@ data structure basically just contains the root module, the HIR
 `Crate` structure contains a number of maps and other things that
 serve to organize the content of the crate for easier access.
 
-For example, the contents of individual items (e.g., modules,
+For example, the contents of individual items (e.g. modules,
 functions, traits, impls, etc) in the HIR are not immediately
 accessible in the parents. So, for example, if there is a module item
 `foo` containing a function `bar()`:

src/macro-expansion.md

@@ -30,7 +30,7 @@ macro_rules! printer {
 `$mvar` is called a _metavariable_. Unlike normal variables, rather than
 binding to a value in a computation, a metavariable binds _at compile time_ to
 a tree of _tokens_.  A _token_ is a single "unit" of the grammar, such as an
-identifier (e.g., `foo`) or punctuation (e.g., `=>`). There are also other
+identifier (e.g. `foo`) or punctuation (e.g. `=>`). There are also other
 special tokens, such as `EOF`, which indicates that there are no more tokens.
 Token trees resulting from paired parentheses-like characters (`(`...`)`,
 `[`...`]`, and `{`...`}`) – they include the open and close and all the tokens

src/query.md

@@ -25,7 +25,7 @@ will in turn demand information about that crate, starting from the
 *end*.  For example:
 
 - This "compile" query might demand to get a list of codegen-units
-  (i.e., modules that need to be compiled by LLVM).
+  (i.e. modules that need to be compiled by LLVM).
 - But computing the list of codegen-units would invoke some subquery
   that returns the list of all modules defined in the Rust source.
 - That query in turn would invoke something asking for the HIR.
@@ -134,7 +134,7 @@ fn provider<'cx, 'tcx>(tcx: TyCtxt<'cx, 'tcx, 'tcx>,
 ```
 
 Providers take two arguments: the `tcx` and the query key. Note also
-that they take the *global* tcx (i.e., they use the `'tcx` lifetime
+that they take the *global* tcx (i.e. they use the `'tcx` lifetime
 twice), rather than taking a tcx with some active inference context.
 They return the result of the query.
 

src/trait-resolution.md

@@ -408,7 +408,7 @@ if we had a trait reference `usize : Foo<$1>`, where `$n` is an unbound
 inference variable, we might replace it with `usize : Foo<%0>`, where
 `%n` is a skolemized type. We would then look this up in the cache.
 If we found a hit, the hit would tell us the immediate next step to
-take in the selection process: i.e., apply impl #22, or apply where
+take in the selection process: i.e. apply impl #22, or apply where
 clause `X : Foo<Y>`. Let's say in this case there is no hit.
 Therefore, we search through impls and where clauses and so forth, and
 we come to the conclusion that the only possible impl is this one,

src/type-inference.md

@@ -90,7 +90,7 @@ method, roughly like so:
 infcx.at(...).eq(t, u);
 ```
 
-The first `at()` call provides a bit of context, i.e., why you are
+The first `at()` call provides a bit of context, i.e. why you are
 doing this unification, and in what environment, and the `eq` method
 performs the actual equality constraint.