From 5a9fce427e616e5a95a660ea0d80197dce8f6cb7 Mon Sep 17 00:00:00 2001 From: Alexander Regueiro Date: Mon, 5 Feb 2018 02:15:36 +0000 Subject: [PATCH] Fixed issues mentioned by @mark-i-m in review. --- src/SUMMARY.md | 2 +- src/high-level-overview.md | 12 ++++++------ src/hir.md | 6 +++--- src/trans.md | 2 +- src/type-inference.md | 8 ++++---- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 8f128f64..a2f40ed3 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -19,5 +19,5 @@ - [MIR construction](./mir-construction.md) - [MIR borrowck](./mir-borrowck.md) - [MIR optimizations](./mir-optimizations.md) -- [The `trans` crate: generating LLVM IR](./trans.md) +- [Generating LLVM IR](./trans.md) - [Glossary](./glossary.md) diff --git a/src/high-level-overview.md b/src/high-level-overview.md index 0d3ad8be..49365671 100644 --- a/src/high-level-overview.md +++ b/src/high-level-overview.md @@ -12,10 +12,10 @@ Rustc consists of a number of crates, including `syntax`, many more. The source for each crate can be found in a directory like `src/libXXX`, where `XXX` is the crate name. -(NB. The names and divisions of these crates are not set in -stone and may change over time – for the time being, we tend towards -a finer-grained division to help with compilation time, though as -incremental improves that may change.) +(N.B. The names and divisions of these crates are not set in +stone and may change over time. For the time being, we tend towards a +finer-grained division to help with compilation time, though as incremental +compilation improves, that may change.) The dependency structure of these crates is roughly a diamond: @@ -37,7 +37,7 @@ rustc_trans rustc_borrowck ... rustc_metadata / \ / \ syntax_pos syntax_ext -``` +``` The `rustc_driver` crate, at the top of this lattice, is effectively the "main" function for the rust compiler. It doesn't have much "real @@ -127,7 +127,7 @@ take: 4. **Lowering to MIR and post-processing** - Once type-checking is done, we can lower the HIR into MIR ("middle IR"), which is a **very** desugared version of Rust, well suited to the borrowck but also - certain high-level optimizations. + certain high-level optimizations. 5. **Translation to LLVM and LLVM optimizations** - From MIR, we can produce LLVM IR. - LLVM then runs its various optimizations, which produces a number of `.o` files diff --git a/src/hir.md b/src/hir.md index 504f04b2..f78d2add 100644 --- a/src/hir.md +++ b/src/hir.md @@ -59,9 +59,9 @@ sorts of identifiers in active use: - `DefId` – primarily names "definitions" or top-level items. - You can think of a `DefId` as 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 normal Rust (e.g. impls), and they also - include extra information about the crate (such as its version number, since - two versions of the same crate can co-exist). + name things that are not nameable in normal Rust (e.g. `impl`s), and they + also include extra information about the crate (such as its version number, + since two versions of the same crate can co-exist). - A `DefId` really consists of two parts, a `CrateNum` (which identifies the crate) and a `DefIndex` (which indexes into a list of items that is maintained per crate). diff --git a/src/trans.md b/src/trans.md index efff52ef..f5894baa 100644 --- a/src/trans.md +++ b/src/trans.md @@ -1 +1 @@ -# The `trans` crate: generating LLVM IR +# Generating LLVM IR diff --git a/src/type-inference.md b/src/type-inference.md index b867c99e..5e51c735 100644 --- a/src/type-inference.md +++ b/src/type-inference.md @@ -1,8 +1,8 @@ # Type inference -The type inference is based on the standard Hindley–Milner (HM) system, -but extended in various way to accommodate subtyping, region inference, -and higher-ranked types. +The type inference is based on the standard Hindley-Milner (HM) type inference +algorithm, but extended in various way to accommodate subtyping, region +inference, and higher-ranked types. ## A note on terminology @@ -12,7 +12,7 @@ existential variables. We use the terms "region" and "lifetime" interchangeably. Both refer to the `'a` in `&'a T`. -The term "bound region" refers to a region bound in a function +The term "bound region" refers to a region that is a bound in a function signature, such as the `'a` in `for<'a> fn(&'a u32)`. A region is "free" if it is not bound.