Hard-wrapped lines that are too long.

Author: Alexander Regueiro

ci/check_line_lengths.sh

@@ -14,7 +14,7 @@ for file in "$@" ; do
       (( inside_block = !$inside_block ))
       continue
     fi
-    if ! (( $inside_block )) && ! [[ "$line" =~ " | "|"://"|\[\^[^\ ]+\]: ]] && (( "${#line}" > $MAX_LINE_LENGTH )) ; then
+    if ! (( $inside_block )) && ! [[ "$line" =~ " | "|"-|-"|"://"|\[\^[^\ ]+\]: ]] && (( "${#line}" > $MAX_LINE_LENGTH )) ; then
       (( bad_lines++ ))
       echo -e "\t$line_no : $line"
     fi

src/SUMMARY.md

@@ -6,7 +6,8 @@
 - [The compiler testing framework](./tests/intro.md)
     - [Running tests](./tests/running.md)
     - [Adding new tests](./tests/adding.md)
-    - [Using `compiletest` + commands to control test execution](./compiletest.md)
+    - [Using `compiletest` + commands to control test
+      execution](./compiletest.md)
 - [Walkthrough: a typical contribution](./walkthrough.md)
 - [High-level overview of the compiler source](./high-level-overview.md)
 - [The Rustc Driver](./rustc-driver.md)

src/compiletest.md

@@ -1,8 +1,10 @@
 # `compiletest`
 ## Introduction
-`compiletest` is the main test harness of the Rust test suite.  It allows test authors to organize large numbers of tests (the
-Rust compiler has many thousands), efficient test execution (parallel execution is supported), and allows the test author to
-configure behavior and expected results of both individual and groups of tests.
+`compiletest` is the main test harness of the Rust test suite.  It allows
+test authors to organize large numbers of tests (the Rust compiler has many
+thousands), efficient test execution (parallel execution is supported), and
+allows the test author to configure behavior and expected results of both
+individual and groups of tests.
 
 `compiletest` tests may check test code for success, for failure or in some cases, even failure to compile.  Tests are
 typically organized as a Rust source file with annotations in comments before and/or within the test code, which serve to
@@ -12,17 +14,17 @@ testing framework, see [`this chapter`](./tests/intro.html) for additional backg
 The tests themselves are typically (but not always) organized into "suites"--for example, `run-pass`, a folder
 representing tests that should succeed, `run-fail`, a folder holding tests that should compile successfully, but return
 a failure (non-zero status), `compile-fail`, a folder holding tests that should fail to compile, and many more.  The various
-suites are defined in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs) in the `pub struct Config` declaration.  And a very good 
+suites are defined in [src/tools/compiletest/src/common.rs](https://github.com/rust-lang/rust/tree/master/src/tools/compiletest/src/common.rs) in the `pub struct Config` declaration.  And a very good
 introduction to the different suites of compiler tests along with details about them can be found in [`Adding new tests`](./tests/adding.html).
 
 ## Adding a new test file
-Briefly, simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test).  No registration of test files is necessary as 
+Briefly, simply create your new test in the appropriate location under [src/test](https://github.com/rust-lang/rust/tree/master/src/test).  No registration of test files is necessary as
 `compiletest` will scan the [src/test](https://github.com/rust-lang/rust/tree/master/src/test) subfolder recursively, and will execute any Rust source files it finds as tests.
-See [`Adding new tests`](./tests/adding.html) for a complete guide on how to adding new tests. 
+See [`Adding new tests`](./tests/adding.html) for a complete guide on how to adding new tests.
 
 ## Header Commands
 Source file annotations which appear in comments near the top of the source file *before* any test code are known as header
-commands.  These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to 
+commands.  These commands can instruct `compiletest` to ignore this test, set expectations on whether it is expected to
 succeed at compiling, or what the test's return code is expected to be.  Header commands (and their inline counterparts,
 Error Info commands) are described more fully [here](./tests/adding.html#header-commands-configuring-rustc).
 
@@ -96,7 +98,7 @@ As a concrete example, here is the implementation for the `parse_failure_status(
      pub normalize_stderr: Vec<(String, String)>,
 +    pub failure_status: i32,
  }
- 
+
  impl TestProps {
 @@ -260,6 +261,7 @@ impl TestProps {
              run_pass: false,
@@ -105,7 +107,7 @@ As a concrete example, here is the implementation for the `parse_failure_status(
 +            failure_status: 101,
          }
      }
- 
+
 @@ -383,6 +385,10 @@ impl TestProps {
              if let Some(rule) = config.parse_custom_normalization(ln, "normalize-stderr") {
                  self.normalize_stderr.push(rule);
@@ -115,12 +117,12 @@ As a concrete example, here is the implementation for the `parse_failure_status(
 +                self.failure_status = code;
 +            }
          });
- 
+
          for key in &["RUST_TEST_NOCAPTURE", "RUST_TEST_THREADS"] {
 @@ -488,6 +494,13 @@ impl Config {
          self.parse_name_directive(line, "pretty-compare-only")
      }
- 
+
 +    fn parse_failure_status(&self, line: &str) -> Option<i32> {
 +        match self.parse_name_value_directive(line, "failure-status") {
 +            Some(code) => code.trim().parse::<i32>().ok(),
@@ -141,7 +143,7 @@ located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/r
 ```diff
 @@ -295,11 +295,14 @@ impl<'test> TestCx<'test> {
      }
- 
+
      fn check_correct_failure_status(&self, proc_res: &ProcRes) {
 -        // The value the rust runtime returns on failure
 -        const RUST_ERR: i32 = 101;
@@ -160,7 +162,7 @@ located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/r
          }
 @@ -320,7 +323,6 @@ impl<'test> TestCx<'test> {
          );
- 
+
          let proc_res = self.exec_compiled_test();
 -
          if !proc_res.status.success() {
@@ -172,7 +174,7 @@ located in [src/tools/compiletest/src/runtest.rs](https://github.com/rust-lang/r
              );
 -            panic!();
          }
-     }    
+     }
 ```
 Note the use of `self.props.failure_status` to access the header command property.  In tests which do not specify the failure
 status header command, `self.props.failure_status` will evaluate to the default value of 101 at the time of this writing.

src/high-level-overview.md

@@ -94,20 +94,21 @@ order to compile a Rust crate, these are the general steps that we
 take:
 
 1. **Parsing input**
-    - this processes the `.rs` files and produces the AST ("abstract syntax tree")
+    - this processes the `.rs` files and produces the AST
+      ("abstract syntax tree")
     - the AST is defined in `syntax/ast.rs`. It is intended to match the lexical
       syntax of the Rust language quite closely.
 2. **Name resolution, macro expansion, and configuration**
-    - once parsing is complete, we process the AST recursively, resolving paths
-      and expanding macros. This same process also processes `#[cfg]` nodes, and hence
-      may strip things out of the AST as well.
+    - once parsing is complete, we process the AST recursively, resolving
+      paths and expanding macros. This same process also processes `#[cfg]`
+      nodes, and hence may strip things out of the AST as well.
 3. **Lowering to HIR**
     - Once name resolution completes, we convert the AST into the HIR,
-      or "high-level IR". The HIR is defined in `src/librustc/hir/`; that module also includes
-      the lowering code.
-    - The HIR is a lightly desugared variant of the AST. It is more processed than the
-      AST and more suitable for the analyses that follow. It is **not** required to match
-      the syntax of the Rust language.
+      or "high-level IR". The HIR is defined in `src/librustc/hir/`;
+      that module also includes the lowering code.
+    - The HIR is a lightly desugared variant of the AST. It is more processed
+      than the AST and more suitable for the analyses that follow.
+      It is **not** required to match the syntax of the Rust language.
     - As a simple example, in the **AST**, we preserve the parentheses
       that the user wrote, so `((1 + 2) + 3)` and `1 + 2 + 3` parse
       into distinct trees, even though they are equivalent. In the
@@ -125,13 +126,13 @@ take:
       the types of expressions, the way to resolve methods, and so forth.
     - After type-checking, we can do other analyses, such as privacy checking.
 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.
+    - 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 borrowck
+      but also to 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
-      (one for each "codegen unit").
+    - LLVM then runs its various optimizations, which produces a number of
+      `.o` files (one for each "codegen unit").
 6. **Linking**
     - Finally, those `.o` files are linked together.
 

src/hir.md

@@ -63,23 +63,25 @@ 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` – 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. `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).
-- `HirId` – combines the index of a particular item with an offset within
-  that item.
-  - The key point of an `HirId` is that it is *relative* to some item (which is
-    named via a `DefId`).
-- `BodyId` – an absolute identifier that refers to a specific body (definition
-  of a function or constant) in the crate. It is currently effectively a
-  "newtype'd" `NodeId`.
-- `NodeId` – an absolute ID that identifies a single node in the HIR tree.
+- `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
+    normal Rust (e.g. impls), and they also include extra information
+    about the crate (such as its version number, as 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 indixes into a list
+    of items that is maintained per crate).
+- `HirId`, which combines the index of a particular item with an
+  offset within that item.
+  - the key point of a `HirId` is that it is *relative* to some item
+    (which is named via a `DefId`).
+- `BodyId`, this is an absolute identifier that refers to a specific
+  body (definition of a function or constant) in the crate. It is currently
+  effectively a "newtype'd" `NodeId`.
+- `NodeId`, which is an absolute id that identifies a single node in the HIR
+  tree.
   - While these are still in common use, **they are being slowly phased out**.
   - Since they are absolute within the crate, adding a new node anywhere in the
     tree causes the `NodeId`s of all subsequent code in the crate to change.
@@ -119,5 +121,5 @@ 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. an `fn()` or `const`), but could also be a closure expression
 (e.g. `|x, y| x + y`). You can use the HIR map to find the body
-associated with a given `DefId` (`maybe_body_owned_by()`) or to find
+associated with a given def-id (`maybe_body_owned_by()`) or to find
 the owner of a body (`body_owner_def_id()`).

src/how-to-build-and-run.md

@@ -2,8 +2,9 @@
 
 The compiler is built using a tool called `x.py`. You will need to
 have Python installed to run it. But before we get to that, if you're going to
-be hacking on rustc, you'll want to tweak the configuration of the compiler. The default
-configuration is oriented towards running the compiler as a user, not a developer.
+be hacking on rustc, you'll want to tweak the configuration of the compiler.
+The default configuration is oriented towards running the compiler as a user,
+not a developer.
 
 ### Create a config.toml
 
@@ -84,15 +85,16 @@ What this command will do is the following:
 - Using this stage 1 compiler, it will build the standard library.
   (this is what the `src/libstd`) means.
 
-This is just a subset of the full rustc build. The **full** rustc build (what you
-get if you just say `./x.py build`) has quite a few more steps:
+This is just a subset of the full rustc build. The **full** rustc build
+(what you get if you just say `./x.py build`) has quite a few more steps:
 
-- Build stage1 rustc with stage0 compiler
-- Build libstd with stage1 compiler (up to here is the same)
-- Build rustc from `src` again, this time with the stage1 compiler (this part is new)
-  - The resulting compiler here is called the "stage2" compiler
-- Build libstd with stage2 compiler
-- Build librustdoc and a bunch of other things
+- Build stage1 rustc with stage0 compiler.
+- Build libstd with stage1 compiler (up to here is the same).
+- Build rustc from `src` again, this time with the stage1 compiler
+  (this part is new).
+  - The resulting compiler here is called the "stage2" compiler.
+- Build libstd with stage2 compiler.
+- Build librustdoc and a bunch of other things.
 
 ### Creating a rustup toolchain
 
@@ -126,12 +128,16 @@ LLVM version: 4.0
 
 ### Other x.py commands
 
-Here are a few other useful x.py commands. We'll cover some of them in detail in other sections:
+Here are a few other useful x.py commands. We'll cover some of them in detail
+in other sections:
 
 - Building things:
-  - `./x.py clean` – clean up the build directory (`rm -rf build` works too, but then you have to rebuild LLVM)
-  - `./x.py build --stage 1` – builds everything using the stage 1 compiler, not just up to libstd
+  - `./x.py clean` – clean up the build directory (`rm -rf build` works too,
+    but then you have to rebuild LLVM)
+  - `./x.py build --stage 1` – builds everything using the stage 1 compiler,
+    not just up to libstd
   - `./x.py build` – builds the stage2 compiler
-- Running tests (see the [section on running tests](./tests/running.html) for more details):
+- Running tests (see the [section on running tests](./tests/running.html) for
+  more details):
   - `./x.py test --stage 1 src/libstd` – runs the `#[test]` tests from libstd
   - `./x.py test --stage 1 src/test/run-pass` – runs the `run-pass` test suite

src/incremental-compilation.md

@@ -2,8 +2,8 @@
 
 The incremental compilation scheme is, in essence, a surprisingly
 simple extension to the overall query system. We'll start by describing
-a slightly simplified variant of the real thing – the "basic algorithm" – and then describe
-some possible improvements.
+a slightly simplified variant of the real thing – the "basic algorithm" –
+and then describe some possible improvements.
 
 ## The basic algorithm
 
@@ -40,7 +40,7 @@ There are two key insights here:
     produced the same result as the previous time. **If it did,** we
     can still mark the query as green, and hence avoid re-executing
     dependent queries.
-    
+
 ### The try-mark-green algorithm
 
 At the core of incremental compilation is an algorithm called
@@ -66,28 +66,30 @@ Try-mark-green works as follows:
   - For each query R in `reads(Q)`, we recursively demand the color
     of R using try-mark-green.
     - Note: it is important that we visit each node in `reads(Q)` in same order
-      as they occurred in the original compilation. See [the section on the query DAG below](#dag).
-    - If **any** of the nodes in `reads(Q)` wind up colored **red**, then Q is dirty.
-      - We re-execute Q and compare the hash of its result to the hash of the result
-        from the previous compilation.
+      as they occurred in the original compilation. See [the section on the
+      query DAG below](#dag).
+    - If **any** of the nodes in `reads(Q)` wind up colored **red**, then Q is
+      dirty.
+      - We re-execute Q and compare the hash of its result to the hash of the
+        result from the previous compilation.
       - If the hash has not changed, we can mark Q as **green** and return.
-    - Otherwise, **all** of the nodes in `reads(Q)` must be **green**. In that case,
-      we can color Q as **green** and return.
+    - Otherwise, **all** of the nodes in `reads(Q)` must be **green**. In that
+      case, we can color Q as **green** and return.
 
 <a name="dag">
 
 ### The query DAG
 
 The query DAG code is stored in
 [`src/librustc/dep_graph`][dep_graph]. Construction of the DAG is done
-by instrumenting the query execution. 
+by instrumenting the query execution.
 
 One key point is that the query DAG also tracks ordering; that is, for
 each query Q, we not only track the queries that Q reads, we track the
 **order** in which they were read.  This allows try-mark-green to walk
-those queries back in the same order. This is important because once a subquery comes back as red,
-we can no longer be sure that Q will continue along the same path as before.
-That is, imagine a query like this:
+those queries back in the same order. This is important because once a
+subquery comes back as red, we can no longer be sure that Q will continue
+along the same path as before. That is, imagine a query like this:
 
 ```rust,ignore
 fn main_query(tcx) {
@@ -105,9 +107,10 @@ query `main_query` executes will be `subquery2`, and `subquery3` will
 not be executed at all.
 
 But now imagine that in the **next** compilation, the input has
-changed such that `subquery1` returns **false**. In this case, `subquery2` would never
-execute. If try-mark-green were to visit `reads(main_query)` out of order,
-however, it might visit `subquery2` before `subquery1`, and hence execute it.
+changed such that `subquery1` returns **false**. In this case, `subquery2`
+would never execute. If try-mark-green were to visit `reads(main_query)` out
+of order, however, it might visit `subquery2` before `subquery1`, and hence
+execute it.
 This can lead to ICEs and other problems in the compiler.
 
 [dep_graph]: https://github.com/rust-lang/rust/tree/master/src/librustc/dep_graph
@@ -124,8 +127,8 @@ we **also** save the results.
 
 This is why the incremental algorithm separates computing the
 **color** of a node, which often does not require its value, from
-computing the **result** of a node. Computing the result is done via a simple algorithm
-like so:
+computing the **result** of a node. Computing the result is done via a simple
+algorithm like so:
 
 - Check if a saved result for Q is available. If so, compute the color of Q.
   If Q is green, deserialize and return the saved result.