Fix all the links to be relative for mdbook 2

Author: mark-i-m

src/appendix/background.md

@@ -94,7 +94,7 @@ and Michael I. Schwartzbach is an incredible resource!
 Check out the subtyping chapter from the
 [Rust Nomicon](https://doc.rust-lang.org/nomicon/subtyping.html).
 
-See the [variance](./variance.html) chapter of this guide for more info on how
+See the [variance](../variance.html) chapter of this guide for more info on how
 the type checker handles variance.
 
 <a name="free-vs-bound"></a>

src/appendix/code-index.md

@@ -29,16 +29,16 @@ Item            |  Kind    | Short description           | Chapter            |
 `Ty<'tcx>` | struct | This is the internal representation of a type used for type checking | [Type checking] | [src/librustc/ty/mod.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/type.Ty.html)
 `TyCtxt<'cx, 'tcx, 'tcx>` | type | The "typing context". This is the central data structure in the compiler. It is the context that you use to perform all manner of queries | [The `ty` modules] | [src/librustc/ty/context.rs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.TyCtxt.html)
 
-[The HIR]: hir.html
-[Identifiers in the HIR]: hir.html#hir-id
-[The parser]: the-parser.html
-[The Rustc Driver]: rustc-driver.html
-[Type checking]: type-checking.html
-[The `ty` modules]: ty.html
-[Rustdoc]: rustdoc.html
-[Emitting Diagnostics]: diag.html
-[Macro expansion]: macro-expansion.html
-[Name resolution]: name-resolution.html
-[Parameter Environment]: param_env.html
-[Trait Solving: Goals and Clauses]: traits/goals-and-clauses.html#domain-goals
-[Trait Solving: Lowering impls]: traits/lowering-rules.html#lowering-impls
+[The HIR]: ../hir.html
+[Identifiers in the HIR]: ../hir.html#hir-id
+[The parser]: ../the-parser.html
+[The Rustc Driver]: ../rustc-driver.html
+[Type checking]: ../type-checking.html
+[The `ty` modules]: ../ty.html
+[Rustdoc]: ../rustdoc.html
+[Emitting Diagnostics]: ../diag.html
+[Macro expansion]: ../macro-expansion.html
+[Name resolution]: ../name-resolution.html
+[Parameter Environment]: ../param_env.html
+[Trait Solving: Goals and Clauses]: ../traits/goals-and-clauses.html#domain-goals
+[Trait Solving: Lowering impls]: ../traits/lowering-rules.html#lowering-impls

src/appendix/glossary.md

@@ -12,7 +12,7 @@ enforcing a number of properties:
 - etc
 
 At the time of this writing, the code is in a state of transition. The
-"main" borrow checker still works by processing [the HIR](hir.html),
+"main" borrow checker still works by processing [the HIR](../hir.html),
 but that is being phased out in favor of the MIR-based borrow checker.
 Doing borrow checking on MIR has two key advantages:
 
@@ -43,15 +43,15 @@ The overall flow of the borrow checker is as follows:
   include references to the new regions that we are computing.
 - We then invoke `nll::replace_regions_in_mir` to modify this copy C.
   Among other things, this function will replace all of the regions in
-  the MIR with fresh [inference variables](./appendix/glossary.html).
-  - (More details can be found in [the regionck section](./mir/regionck.html).)
+  the MIR with fresh [inference variables](../appendix/glossary.html).
+  - (More details can be found in [the regionck section](./regionck.html).)
 - Next, we perform a number of [dataflow
-  analyses](./appendix/background.html#dataflow)
+  analyses](../appendix/background.html#dataflow)
   that compute what data is moved and when. The results of these analyses
   are needed to do both borrow checking and region inference.
 - Using the move data, we can then compute the values of all the regions in the
   MIR.
-  - (More details can be found in [the NLL section](./mir/regionck.html).)
+  - (More details can be found in [the NLL section](./regionck.html).)
 - Finally, the borrow checker itself runs, taking as input (a) the
   results of move analysis and (b) the regions computed by the region
   checker. This allows us to figure out which loans are still in scope

src/mir/borrowck.md

@@ -1,7 +1,7 @@
 # The MIR (Mid-level IR)
 
 MIR is Rust's _Mid-level Intermediate Representation_. It is
-constructed from [HIR](./hir.html). MIR was introduced in
+constructed from [HIR](../hir.html). MIR was introduced in
 [RFC 1211]. It is a radically simplified form of Rust that is used for
 certain flow-sensitive safety checks – notably the borrow checker! –
 and also for optimization and code generation.
@@ -26,7 +26,7 @@ Some of the key characteristics of MIR are:
 - It does not have nested expressions.
 - All types in MIR are fully explicit.
 
-[cfg]: ./appendix/background.html#cfg
+[cfg]: ../appendix/background.html#cfg
 
 ## Key MIR vocabulary
 
@@ -244,4 +244,4 @@ but [you can read about those below](#promoted)).
 [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir
 [mirmanip]: https://github.com/rust-lang/rust/tree/master/src/librustc_mir
 [mir]: https://github.com/rust-lang/rust/tree/master/src/librustc/mir
-[newtype'd]: appendix/glossary.html
+[newtype'd]: ../appendix/glossary.html

src/mir/index.md

@@ -156,7 +156,7 @@ then `mir_const_qualif(D)` would succeed if it came before
 `mir_validated(D)`, but fail otherwise. Therefore, `mir_validated(D)`
 will **force** `mir_const_qualif` before it actually steals, thus
 ensuring that the reads have already happened (remember that
-[queries are memoized](./query.html), so executing a query twice
+[queries are memoized](../query.html), so executing a query twice
 simply loads from a cache the second time):
 
 ```text
@@ -174,4 +174,4 @@ alternatives in [rust-lang/rust#41710].
 [rust-lang/rust#41710]: https://github.com/rust-lang/rust/issues/41710
 [mirtransform]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/
 [`NoLandingPads`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/transform/no_landing_pads/struct.NoLandingPads.html
-[MIR visitor]: mir/visitor.html
+[MIR visitor]: ./visitor.html

src/mir/passes.md

@@ -35,7 +35,7 @@ The MIR-based region analysis consists of two major functions:
   - More details to come, though the [NLL RFC] also includes fairly thorough
     (and hopefully readable) coverage.
 
-[fvb]: appendix/background.html#free-vs-bound
+[fvb]: ../appendix/background.html#free-vs-bound
 [NLL RFC]: http://rust-lang.github.io/rfcs/2094-nll.html
 
 ## Universal regions
@@ -131,7 +131,7 @@ the type of `foo`   the type `bar` expects
 We handle this sort of subtyping by taking the variables that are
 bound in the supertype and **skolemizing** them: this means that we
 replace them with
-[universally quantified](appendix/background.html#quantified)
+[universally quantified](../appendix/background.html#quantified)
 representatives, written like `!1`. We call these regions "skolemized
 regions" – they represent, basically, "some unknown region".
 
@@ -148,7 +148,7 @@ what we wanted.
 
 So let's work through what happens next. To check if two functions are
 subtypes, we check if their arguments have the desired relationship
-(fn arguments are [contravariant](./appendix/background.html#variance), so
+(fn arguments are [contravariant](../appendix/background.html#variance), so
 we swap the left and right here):
 
 ```text
@@ -187,7 +187,7 @@ Here, the root universe would consist of the lifetimes `'static` and
 the same concept to types, in which case the types `Foo` and `T` would
 be in the root universe (along with other global types, like `i32`).
 Basically, the root universe contains all the names that
-[appear free](./appendix/background.html#free-vs-bound) in the body of `bar`.
+[appear free](../appendix/background.html#free-vs-bound) in the body of `bar`.
 
 Now let's extend `bar` a bit by adding a variable `x`:
 

src/mir/regionck.md

@@ -5,8 +5,8 @@ by the build system (`x.py test`).  The main test harness for testing
 the compiler itself is a tool called compiletest (sources in the
 [`src/tools/compiletest`]). This section gives a brief overview of how
 the testing framework is setup, and then gets into some of the details
-on [how to run tests](./tests/running.html#ui) as well as
-[how to add new tests](./tests/adding.html).
+on [how to run tests](./running.html#ui) as well as
+[how to add new tests](./adding.html).
 
 [`src/tools/compiletest`]: https://github.com/rust-lang/rust/tree/master/src/tools/compiletest
 
@@ -24,7 +24,7 @@ Here is a brief summary of the test suites as of this writing and what
 they mean. In some cases, the test suites are linked to parts of the manual
 that give more details.
 
-- [`ui`](./tests/adding.html#ui) – tests that check the exact
+- [`ui`](./adding.html#ui) – tests that check the exact
   stdout/stderr from compilation and/or running the test
 - `run-pass` – tests that are expected to compile and execute
   successfully (no panics)
@@ -59,7 +59,7 @@ including:
 - **Tidy** – This is a custom tool used for validating source code
   style and formatting conventions, such as rejecting long lines.
   There is more information in the
-  [section on coding conventions](./conventions.html#formatting).
+  [section on coding conventions](../conventions.html#formatting).
 
   Example: `./x.py test src/tools/tidy`
 

src/tests/intro.md

@@ -17,7 +17,7 @@ type can be referenced by the user using an **associated type
 projection** like `<Option<u32> as IntoIterator>::Item`. (Often,
 though, people will use the shorthand syntax `T::Item` – presently,
 that syntax is expanded during
-["type collection"](./type-checking.html) into the explicit form,
+["type collection"](../type-checking.html) into the explicit form,
 though that is something we may want to change in the future.)
 
 [intoiter-item]: https://doc.rust-lang.org/nightly/core/iter/trait.IntoIterator.html#associatedtype.Item
@@ -130,7 +130,7 @@ any given associated item.
 
 Now we are ready to discuss how associated type equality integrates
 with unification. As described in the
-[type inference](./type-inference.html) section, unification is
+[type inference](../type-inference.html) section, unification is
 basically a procedure with a signature like this:
 
 ```text

src/traits/associated-types.md

@@ -24,7 +24,7 @@ On the other hand, if there is no hit, we need to go through the [selection
 process] from scratch. Suppose, we come to the conclusion that the only
 possible impl is this one, with def-id 22:
 
-[selection process]: ./traits/resolution.html#selection
+[selection process]: ./resolution.html#selection
 
 ```rust,ignore
 impl Foo<isize> for usize { ... } // Impl #22
@@ -34,7 +34,7 @@ We would then record in the cache `usize : Foo<$0> => ImplCandidate(22)`. Next
 we would [confirm] `ImplCandidate(22)`, which would (as a side-effect) unify
 `$t` with `isize`.
 
-[confirm]: ./traits/resolution.html#confirmation
+[confirm]: ./resolution.html#confirmation
 
 Now, at some later time, we might come along and see a `usize :
 Foo<$u>`. When skolemized, this would yield `usize : Foo<$0>`, just as
@@ -61,7 +61,7 @@ to be pretty clearly safe and also still retains a very high hit rate
 **TODO**: it looks like `pick_candidate_cache` no longer exists. In
 general, is this section still accurate at all?
 
-[`ParamEnv`]: ./param_env.html
-[`tcx`]: ./ty.html
+[`ParamEnv`]: ../param_env.html
+[`tcx`]: ../ty.html
 [#18290]: https://github.com/rust-lang/rust/issues/18290
 [#22019]: https://github.com/rust-lang/rust/issues/22019

src/traits/caching.md

@@ -3,11 +3,11 @@
 The "start" of the trait system is the **canonical query** (these are
 both queries in the more general sense of the word – something you
 would like to know the answer to – and in the
-[rustc-specific sense](./query.html)).  The idea is that the type
+[rustc-specific sense](../query.html)).  The idea is that the type
 checker or other parts of the system, may in the course of doing their
 thing want to know whether some trait is implemented for some type
 (e.g., is `u32: Debug` true?). Or they may want to
-[normalize some associated type](./traits/associated-types.html).
+[normalize some associated type](./associated-types.html).
 
 This section covers queries at a fairly high level of abstraction. The
 subsections look a bit more closely at how these ideas are implemented
@@ -106,7 +106,7 @@ value for a type variable, that means that this is the **only possible
 instantiation** that you could use, given the current set of impls and
 where-clauses, that would be provable. (Internally within the solver,
 though, they can potentially enumerate all possible answers. See
-[the description of the SLG solver](./traits/slg.html) for details.)
+[the description of the SLG solver](./slg.html) for details.)
 
 The response to a trait query in rustc is typically a
 `Result<QueryResult<T>, NoSolution>` (where the `T` will vary a bit
@@ -132,7 +132,7 @@ we did find. It consists of four parts:
 - **Region constraints:** these are relations that must hold between
   the lifetimes that you supplied as inputs. We'll ignore these here,
   but see the
-  [section on handling regions in traits](./traits/regions.html) for
+  [section on handling regions in traits](./regions.html) for
   more details.
 - **Value:** The query result also comes with a value of type `T`. For
   some specialized queries – like normalizing associated types –
@@ -219,7 +219,7 @@ As a result of this assignment, the type of `u` is forced to be
 `Option<Vec<?V>>`, where `?V` represents the element type of the
 vector. This in turn implies that `?U` is [unified] to `Vec<?V>`.
 
-[unified]: ./type-checking.html
+[unified]: ../type-checking.html
 
 Let's suppose that the type checker decides to revisit the
 "as-yet-unproven" trait obligation we saw before, `Vec<?T>:

src/traits/canonical-queries.md

@@ -6,7 +6,7 @@ from its context. It is a key part of implementing
 to get more context.
 
 Canonicalization is really based on a very simple concept: every
-[inference variable](./type-inference.html#vars) is always in one of
+[inference variable](../type-inference.html#vars) is always in one of
 two states: either it is **unbound**, in which case we don't know yet
 what type it is, or it is **bound**, in which case we do. So to
 isolate some data-structure T that contains types/regions from its
@@ -16,7 +16,7 @@ starting from zero and numbered in a fixed order (left to right, for
 the most part, but really it doesn't matter as long as it is
 consistent).
 
-[cq]: ./traits/canonical-queries.html
+[cq]: ./canonical-queries.html
 
 So, for example, if we have the type `X = (?T, ?U)`, where `?T` and
 `?U` are distinct, unbound inference variables, then the canonical
@@ -41,7 +41,7 @@ trait query: `?A: Foo<'static, ?B>`, where `?A` and `?B` are unbound.
 This query contains two unbound variables, but it also contains the
 lifetime `'static`. The trait system generally ignores all lifetimes
 and treats them equally, so when canonicalizing, we will *also*
-replace any [free lifetime](./appendix/background.html#free-vs-bound) with a
+replace any [free lifetime](../appendix/background.html#free-vs-bound) with a
 canonical variable. Therefore, we get the following result:
 
 ```text
@@ -98,12 +98,12 @@ Remember that substitution S though! We're going to need it later.
 
 OK, now that we have a fresh inference context and an instantiated
 query, we can go ahead and try to solve it. The trait solver itself is
-explained in more detail in [another section](./traits/slg.html), but
+explained in more detail in [another section](./slg.html), but
 suffice to say that it will compute a [certainty value][cqqr] (`Proven` or
 `Ambiguous`) and have side-effects on the inference variables we've
 created. For example, if there were only one impl of `Foo`, like so:
 
-[cqqr]: ./traits/canonical-queries.html#query-response
+[cqqr]: ./canonical-queries.html#query-response
 
 ```rust,ignore
 impl<'a, X> Foo<'a, X> for Vec<X>

src/traits/canonicalization.md

@@ -131,18 +131,18 @@ See [The SLG Solver][slg].
 
 [rustc-issues]: https://github.com/rust-lang-nursery/rustc-guide/issues
 [chalk]: https://github.com/rust-lang-nursery/chalk
-[lowering-to-logic]: traits/lowering-to-logic.html
-[lowering-rules]: traits/lowering-rules.html
+[lowering-to-logic]: ./lowering-to-logic.html
+[lowering-rules]: ./lowering-rules.html
 [ast]: https://en.wikipedia.org/wiki/Abstract_syntax_tree
 [chalk-ast]: https://github.com/rust-lang-nursery/chalk/blob/master/chalk-parse/src/ast.rs
 [universal quantification]: https://en.wikipedia.org/wiki/Universal_quantification
-[lowering-forall]: ./traits/lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses
+[lowering-forall]: ./lowering-to-logic.html#type-checking-generic-functions-beyond-horn-clauses
 [programclause]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L721
 [clause]: https://github.com/rust-lang-nursery/chalk/blob/master/GLOSSARY.md#clause
-[goals-and-clauses]: ./traits/goals-and-clauses.html
+[goals-and-clauses]: ./goals-and-clauses.html
 [well-formedness-checks]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir/lowering.rs#L230-L232
 [ir-code]: https://github.com/rust-lang-nursery/chalk/blob/master/src/ir.rs
-[HIR]: hir.html
+[HIR]: ../hir.html
 [binders-struct]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/ir.rs#L661
 [rules-environment]: https://github.com/rust-lang-nursery/chalk/blob/94a1941a021842a5fcb35cd043145c8faae59f08/src/rules.rs#L9
-[slg]: ./traits/slg.html
+[slg]: ./slg.html

src/traits/chalk-overview.md

@@ -2,7 +2,7 @@
 
 In logic programming terms, a **goal** is something that you must
 prove and a **clause** is something that you know is true. As
-described in the [lowering to logic](./traits/lowering-to-logic.html)
+described in the [lowering to logic](./lowering-to-logic.html)
 chapter, Rust's trait solver is based on an extension of hereditary
 harrop (HH) clauses, which extend traditional Prolog Horn clauses with
 a few new superpowers.
@@ -37,7 +37,7 @@ paper
 ["A Proof Procedure for the Logic of Hereditary Harrop Formulas"][pphhf]
 gives the details.
 
-[pphhf]: ./traits/bibliography.html#pphhf
+[pphhf]: ./bibliography.html#pphhf
 
 <a name="domain-goals"></a>
 
@@ -94,20 +94,20 @@ e.g. `ProjectionEq<T as Iterator>::Item = u8`
 
 The given associated type `Projection` is equal to `Type`; this can be proved
 with either normalization or using skolemized types. See [the section
-on associated types](./traits/associated-types.html).
+on associated types](./associated-types.html).
 
 #### Normalize(Projection -> Type)
 e.g. `ProjectionEq<T as Iterator>::Item -> u8`
 
 The given associated type `Projection` can be [normalized][n] to `Type`.
 
 As discussed in [the section on associated
-types](./traits/associated-types.html), `Normalize` implies `ProjectionEq`,
+types](./associated-types.html), `Normalize` implies `ProjectionEq`,
 but not vice versa. In general, proving `Normalize(<T as Trait>::Item -> U)`
 also requires proving `Implemented(T: Trait)`.
 
-[n]: ./traits/associated-types.html#normalize
-[at]: ./traits/associated-types.html
+[n]: ./associated-types.html#normalize
+[at]: ./associated-types.html
 
 #### FromEnv(TraitRef), FromEnv(Projection = Type)
 e.g. `FromEnv(Self: Add<i32>)`
@@ -212,7 +212,7 @@ In addition to auto traits, `WellFormed` predicates are co-inductive.
 These are used to achieve a similar "enumerate all the cases" pattern,
 as described in the section on [implied bounds].
 
-[implied bounds]: ./traits/lowering-rules.html#implied-bounds
+[implied bounds]: ./lowering-rules.html#implied-bounds
 
 ## Incomplete chapter