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

@@ -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/borrow_check/region_inference.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

@@ -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>: