Add a more detailed description of how incremental compilation works.

Author: michaelwoerister

src/SUMMARY.md

@@ -20,8 +20,9 @@
 - [The Rustc Driver](./rustc-driver.md)
     - [Rustdoc](./rustdoc.md)
 - [Queries: demand-driven compilation](./query.md)
-    - [The Query Evaluation Model in Detail](./query-evaluation-model-in-detail.md)
-    - [Incremental compilation](./incremental-compilation.md)
+    - [The Query Evaluation Model in Detail](./queries/query-evaluation-model-in-detail.md)
+    - [Incremental compilation](./queries/incremental-compilation.md)
+    - [Incremental compilation In Detail](./queries/incremental-compilation-in-detail.md)
     - [Debugging and Testing](./incrcomp-debugging.md)
 - [The parser](./the-parser.md)
 - [`#[test]` Implementation](./test-implementation.md)

src/appendix/glossary.md

@@ -15,7 +15,7 @@ completeness            |  completeness is a technical term in type theory. Comp
 control-flow graph      |  a representation of the control-flow of a program; see [the background chapter for more](./background.html#cfg)
 CTFE                    |  Compile-Time Function Evaluation. This is the ability of the compiler to evaluate `const fn`s at compile time. This is part of the compiler's constant evaluation system. ([see more](../const-eval.html))
 cx                      |  we tend to use "cx" as an abbreviation for context. See also `tcx`, `infcx`, etc.
-DAG                     |  a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../incremental-compilation.html))
+DAG                     |  a directed acyclic graph is used during compilation to keep track of dependencies between queries. ([see more](../queries/incremental-compilation.html))
 data-flow analysis      |  a static analysis that figures out what properties are true at each point in the control-flow of a program; see [the background chapter for more](./background.html#dataflow)
 DefId                   |  an index identifying a definition (see `librustc/hir/def_id.rs`). Uniquely identifies a `DefPath`.
 Double pointer          |  a pointer with additional metadata. See "fat pointer" for more.

src/queries/incremental-compilation-in-detail.md

@@ -123,23 +123,24 @@ fn type_check_crate_provider(tcx, _key: ()) {
 }
 ```
 
-We see that the `type_check_crate` query accesses input data (`tcx.hir_map`)
-and invokes other queries (`type_check_item`). The `type_check_item`
+We see that the `type_check_crate` query accesses input data
+(`tcx.hir_map.list_of_items()`) and invokes other queries
+(`type_check_item`). The `type_check_item`
 invocations will themselves access input data and/or invoke other queries,
 so that in the end the DAG of query invocations will be built up backwards
 from the node that was initially executed:
 
-```
-                                                                    (1)
- hir_map <--------------------------------------------------- type_check_crate()
-   ^                                                                |
-   |      (4)           (3)                    (2)                  |
-   +-- Hir(foo) <--- type_of(foo) <--- type_check_item(foo) <-------+
-   |                                       |                        |
-   |                     +-----------------+                        |
-   |                     |                                          |
-   |     (6)             v (5)                 (7)                  |
-   +-- Hir(bar) <--- type_of(bar) <--- type_check_item(bar) <-------+
+```ignore
+         (2)                                                 (1)
+  list_of_all_hir_items <----------------------------- type_check_crate()
+                                                               |
+    (5)             (4)                  (3)                   |
+  Hir(foo) <--- type_of(foo) <--- type_check_item(foo) <-------+
+                                      |                        |
+                    +-----------------+                        |
+                    |                                          |
+    (7)             v  (6)                  (8)                |
+  Hir(bar) <--- type_of(bar) <--- type_check_item(bar) <-------+
 
 // (x) denotes invocation order
 ```

src/incremental-compilation.md renamed to src/queries/incremental-compilation.md

@@ -37,8 +37,8 @@ compiler (for example, generating MIR) work exactly like this.
 
 ### The Query Evaluation Model in Detail
 
-The [Query Evaluation Model in Detail](query-evaluation-model-in-detail.html)
-chapter gives a more in-depth description of what queries are and how they work.
+The [Query Evaluation Model in Detail][query-model] chapter gives a more
+in-depth description of what queries are and how they work.
 If you intend to write a query of your own, this is a good read.
 
 ### Invoking queries
@@ -267,3 +267,4 @@ impl<'tcx> QueryDescription for queries::type_of<'tcx> {
 }
 ```
 
+[query-model]: queries/query-evaluation-model-in-detail.html

src/queries/query-evaluation-model-in-detail.md

@@ -139,7 +139,7 @@ crate (through `crate_variances`), but since most changes will not result in a
 change to the actual results from variance inference, the `variances_of` query
 will wind up being considered green after it is re-evaluated.
 
-[rga]: ./incremental-compilation.html
+[rga]: ./queries/incremental-compilation.html
 
 <a name="addendum"></a>