Fix links.

Author: crlf0710

book/src/canonical_queries/canonicalization.md

@@ -6,8 +6,8 @@ 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
-two states: either it is **unbound**, in which case we don't know yet
+[inference variable](https://rustc-dev-guide.rust-lang.org/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
 environment, we just walk down and find the unbound variables that
@@ -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]: ./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](https://rustc-dev-guide.rust-lang.org/appendix/background.html#free-vs-bound) with a
 canonical variable (Note that `'static` is actually a _free_ lifetime 
 variable here. We are not considering it in the typing context of the whole 
 program but only in the context of this trait reference. Mathematically, we
@@ -102,12 +102,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](./slg.html), but
+explained in more detail in [another section](../engine/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]: ./canonical-queries.html#query-response
+[cqqr]: ../canonical_queries.html#query-response
 
 ```rust,ignore
 impl<'a, X> Foo<'a, X> for Vec<X>

book/src/clauses/goals_and_clauses.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](./lowering-to-logic.html)
+described in the [lowering to logic](../clauses.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.
@@ -41,7 +41,7 @@ In terms of code, these types are defined in
 [`librustc_middle/traits/mod.rs`][traits_mod] in rustc, and in
 [`chalk-ir/src/lib.rs`][chalk_ir] in chalk.
 
-[pphhf]: ./bibliography.html#pphhf
+[pphhf]: ../bibliography.html#pphhf
 [traits_mod]: https://github.com/rust-lang/rust/blob/master/src/librustc_middle/traits/mod.rs
 [chalk_ir]: https://github.com/rust-lang/chalk/blob/master/chalk-ir/src/lib.rs
 
@@ -118,20 +118,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 placeholder associated types. See
-[the section on associated types](./associated-types.html).
+[the section on associated types](./type_equality.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](./associated-types.html), `Normalize` implies `ProjectionEq`,
+types](./type_equality.html), `Normalize` implies `ProjectionEq`,
 but not vice versa. In general, proving `Normalize(<T as Trait>::Item -> U)`
 also requires proving `Implemented(T: Trait)`.
 
-[n]: ./associated-types.html#normalize
-[at]: ./associated-types.html
+[n]: ./type_equality.html#normalize
+[at]: ./type_equality.html
 
 #### FromEnv(TraitRef)
 e.g. `FromEnv(Self: Add<i32>)`
@@ -260,4 +260,4 @@ 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]: ./lowering-rules.html#implied-bounds
+[implied bounds]: ./lowering_rules.html#implied-bounds

book/src/clauses/implied_bounds.md

@@ -89,7 +89,7 @@ works for outlive requirements, super trait bounds, and bounds on associated
 types. The full RFC can be found [here][RFC]. We'll give here a brief view
 of how implied bounds work and why we chose to implement it that way. The
 complete set of lowering rules can be found in the corresponding
-[chapter](./lowering-rules.md).
+[chapter](./lowering_rules.md).
 
 [RFC]: https://github.com/rust-lang/rfcs/blob/master/text/2089-implied-bounds.md
 
@@ -449,7 +449,7 @@ this clearly is a cycle and cycles are usually rejected by the trait solver,
 unless...  if the `WellFormed` predicate was made to be co-inductive.
 
 A co-inductive predicate, as discussed in the chapter on
-[goals and clauses](./goals-and-clauses.md#coinductive-goals), are predicates
+[goals and clauses](./goals_and_clauses.html#coinductive-goals), are predicates
 for which the
 trait solver accepts cycles. In our setting, this would be a valid thing to do:
 indeed, the `WellFormed` predicate just serves as a way of enumerating all

book/src/clauses/lowering_rules.md

@@ -4,8 +4,8 @@ This section gives the complete lowering rules for Rust traits into
 [program clauses][pc]. It is a kind of reference. These rules
 reference the [domain goals][dg] defined in an earlier section.
 
-[pc]: ./goals-and-clauses.html
-[dg]: ./goals-and-clauses.html#domain-goals
+[pc]: ./goals_and_clauses.html
+[dg]: ./goals_and_clauses.html#domain-goals
 
 ## Notation
 
@@ -16,7 +16,7 @@ The nonterminal `Ai` is used to mean some generic *argument*, which
 might be a lifetime like `'a` or a type like `Vec<A>`.
 
 When defining the lowering rules, we will give goals and clauses in
-the [notation given in this section](./goals-and-clauses.html).
+the [notation given in this section](./goals_and_clauses.html).
 We sometimes insert "macros" like `LowerWhereClause!` into these
 definitions; these macros reference other sections within this chapter.
 
@@ -107,7 +107,7 @@ The next few clauses have to do with implied bounds (see also
 cover). For each trait, we produce two clauses:
 
 [RFC 2089]: https://rust-lang.github.io/rfcs/2089-implied-bounds.html
-[implied_bounds]: ./implied-bounds.md
+[implied_bounds]: ./implied_bounds.md
 
 ```text
 // Rule Implied-Bound-From-Trait
@@ -147,7 +147,7 @@ This `WellFormed` rule states that `T: Trait` is well-formed if (a)
 `T: Trait` is implemented and (b) all the where-clauses declared on
 `Trait` are well-formed (and hence they are implemented). Remember
 that the `WellFormed` predicate is
-[coinductive](./goals-and-clauses.html#coinductive); in this
+[coinductive](./goals_and_clauses.html#coinductive); in this
 case, it is serving as a kind of "carrier" that allows us to enumerate
 all the where clauses that are transitively implied by `T: Trait`.
 
@@ -272,7 +272,7 @@ where WC
 
 We will produce a number of program clauses. The first two define
 the rules by which `ProjectionEq` can succeed; these two clauses are discussed
-in detail in the [section on associated types](./associated-types.html),
+in detail in the [section on associated types](./type_equality.html),
 but reproduced here for reference:
 
 ```text

book/src/clauses/type_equality.md

@@ -17,7 +17,7 @@ type can be referenced by the user using an **associated type
 projection** like `<Option<u32> as IntoIterator>::Item`.
 
 > Often, people will use the shorthand syntax `T::Item`. Presently, that
-> syntax is expanded during ["type collection"](../type-checking.html) into the
+> syntax is expanded during ["type collection"](https://rustc-dev-guide.rust-lang.org/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
@@ -141,8 +141,8 @@ 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
-basically a procedure with a signature like this:
+[type inference](https://rustc-dev-guide.rust-lang.org/type-inference.html)
+section, unification is basically a procedure with a signature like this:
 
 ```text
 Unify(A, B) = Result<(Subgoals, RegionConstraints), NoSolution>

book/src/clauses/wf.md

@@ -8,7 +8,7 @@ the trait.
 
 For each declaration in a Rust program, we will generate a logical goal and try
 to prove it using the lowered rules we described in the
-[lowering rules](./lowering-rules.md) chapter. If we are able to prove it, we
+[lowering rules](./lowering_rules.md) chapter. If we are able to prove it, we
 say that the construct is well-formed. If not, we report an error to the user.
 
 Well-formedness checking happens in the [`chalk/chalk-solve/src/wf.rs`][wf]
@@ -285,7 +285,7 @@ the input types of `SomeType<A2...>` are well-formed, we prove that
 `WellFormed(SomeType<A2...>: Trait<A1...>)` hold. That is, we want to prove
 that `SomeType<A2...>` verify all the where clauses that might transitively
 be required by the `Trait` definition (see
-[this subsection](./implied-bounds.md#co-inductiveness-of-wellformed)).
+[this subsection](./implied_bounds.md#co-inductiveness-of-wellformed)).
 
 Lastly, assuming in addition that the where clauses on the associated type
 `WC_assoc` hold,

book/src/engine/logic/coinduction.md

@@ -291,4 +291,4 @@ What happens here is that we get an initial answer from `C1` that looks like:
 C1(44) :- C1(22) |
 ```
 
-Ensure root answer will thus try to refine by trying to solve `C1(22)`. Interestingly, this is going to go to a distinct table, because the canonical form is not the same, but that table will just fail.
+Ensure root answer will thus try to refine by trying to solve `C1(22)`. Interestingly, this is going to go to a distinct table, because the canonical form is not the same, but that table will just fail.

book/src/engine/slg.md

@@ -8,7 +8,7 @@ For example, `exists<T> { Vec<T>: FromIterator<u32> }` has one solution, so
 its result is `Unique; substitution [?T := u32]`. A solution also comes with
 a set of region constraints, which we'll ignore in this introduction.
 
-[lowering]: ./lowering-rules.html
+[lowering]: ../clauses.html
 
 ## Goals of the Solver
 
@@ -23,7 +23,7 @@ done. This is similar to how Prolog works.
 
 *See also: [The traditional, interactive Prolog query][pq]*
 
-[pq]: ./canonical-queries.html#the-traditional-interactive-prolog-query
+[pq]: ../canonical_queries.html#the-traditional-interactive-prolog-query
 
 ### Breadth-first
 
@@ -246,7 +246,7 @@ applied to the table goal; actually, in the code, the goals for each
 X-clause are also represented as substitutions, but in this exposition
 I've chosen to write them as full goals, following [NFTD].
 
-[NFTD]: ./bibliography.html#slg
+[NFTD]: ../bibliography.html#slg
 
 Since we now have an answer, `ensure_answer(T1, A0)` will return `Ok`
 to the table T0, indicating that answer A0 is available. T0 now has

book/src/types/operations/fold.md

@@ -45,6 +45,8 @@ The overall flow of folding is like this.
    as [`Folder::fold_free_var_ty`], which makes it easier to write
    folders that just intercept *certain* types.
 
+[`Folder::fold_free_var_ty`]: https://rust-lang.github.io/chalk/chalk_ir/fold/trait.Folder.html#method.fold_free_var_ty
+
 Thus, as a user, you can customize folding by:
 
 * Defining your own `Folder` type

book/src/types/rust_types.md

@@ -204,7 +204,7 @@ types. The intention is that, at least when transitioning, rustc would
 implement the `Interner` trait and would map from the [`TyKind`]
 enum to chalk's `TyData` on the fly, when `data()` is invoked.
 
-[`TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/enum.TyKind.html
+[`TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
 
 This section describes how each of rustc's variants can be mapped to
 Chalk variants.