Auto merge of #652 - drtychai:master, r=jackh726

Hyperlink protocol changed: HTTP -> HTTPS (#1)

Just as the title says; if the domain supported HTTPS, then the protocol was appropriately changed.

The following ~two~ three sites were the only ones without TLS support configured:
- `wambook.sourceforge.net`
- `minikanren.org`
- `blog.ezyang.com`

FWIW, I went through and clicked at least one link for each unique FQDN.

Author: bors

GLOSSARY.md

@@ -1,3 +1,3 @@
 # Glossary
 
-Please see [Appendix A: Glossary and terminology](`http://rust-lang.github.io/chalk/book/glossary.html`) in Chalk book.
+Please see [Appendix A: Glossary and terminology](`https://rust-lang.github.io/chalk/book/glossary.html`) in Chalk book.

README.md

@@ -24,23 +24,23 @@ suitable reference.
 [Prolog]: https://en.wikipedia.org/wiki/Prolog
 [Chalkidiki]: https://en.wikipedia.org/wiki/Chalkidiki
 [Aristotle]: https://en.wikipedia.org/wiki/Aristotle
-[chalk-lowering-details]: http://rust-lang.github.io/chalk/book/#chalk-works-by-converting-rust-goals-into-logical-inference-rules
+[chalk-lowering-details]: https://rust-lang.github.io/chalk/book/#chalk-works-by-converting-rust-goals-into-logical-inference-rules
 
 ## Blog posts
 [blog-posts]: #blog-posts
 Here are some blog posts talking about chalk:
 
-- [Lowering Rust Traits to Logic](http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/)
+- [Lowering Rust Traits to Logic](https://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/)
     - Explains the basic concepts at play
-- [Unification in Chalk, Part 1](http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/)
+- [Unification in Chalk, Part 1](https://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/)
     - An introduction to unification
-- [Unification in Chalk, Part 2](http://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/)
+- [Unification in Chalk, Part 2](https://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/)
     - Extending the system for associated types
-- [Negative reasoning in Chalk](http://aturon.github.io/blog/2017/04/24/negative-chalk/)
+- [Negative reasoning in Chalk](https://aturon.github.io/blog/2017/04/24/negative-chalk/)
     - How to prove that something is not true
-- [Query structure in chalk](http://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/)
+- [Query structure in chalk](https://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/)
     - The basic chalk query structure, with pointers into the chalk implementation
-- [Cyclic queries in chalk](http://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/)
+- [Cyclic queries in chalk](https://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/)
     - Handling cyclic relations and enabling the implementation of implied bounds and other long-desired features in an elegant way
 
 ## REPL

book/mermaid.min.js

@@ -5,13 +5,13 @@ recommended texts and papers:
 
 ## Blog Posts
 
-* [Lowering Rust traits to logic](http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/)
-* [Unification in Chalk, part 1](http://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/)
-* [Unification in Chalk, part 2](http://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/)
+* [Lowering Rust traits to logic](https://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/)
+* [Unification in Chalk, part 1](https://smallcultfollowing.com/babysteps/blog/2017/03/25/unification-in-chalk-part-1/)
+* [Unification in Chalk, part 2](https://smallcultfollowing.com/babysteps/blog/2017/04/23/unification-in-chalk-part-2/)
 * [Negative reasoning in Chalk](https://aturon.github.io/blog/2017/04/24/negative-chalk/)
-* [Query structure in chalk](http://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/)
-* [Cyclic queries in chalk](http://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/)
-* [An on-demand SLG solver for chalk](http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/)
+* [Query structure in chalk](https://smallcultfollowing.com/babysteps/blog/2017/05/25/query-structure-in-chalk/)
+* [Cyclic queries in chalk](https://smallcultfollowing.com/babysteps/blog/2017/09/12/tabling-handling-cyclic-queries-in-chalk/)
+* [An on-demand SLG solver for chalk](https://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/)
 
 ## Papers
 

book/src/bibliography.md

@@ -182,4 +182,4 @@ rule for generic functions like `foo` in our logic.
 This page is a lightly adapted version of a
 [blog post by Nicholas Matsakis][lrtl].
 
-[lrtl]: http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/
+[lrtl]: https://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/

book/src/clauses.md

@@ -7,7 +7,7 @@ This document was previously prepared for the initial design of coherence rules
 > 
 > The role of the orphan rules in particular is basically to prevent you from implementing external traits for external types. So continuing our simple example of `Show`, if you are defining your own library, you could not implement `Show` for `Vec<T>`, because both `Show` and `Vec` are defined in the standard library. But you can implement `Show` for `MyType`, because you defined `MyType`. However, if you define your own trait `MyTrait`, then you can implement `MyTrait` for any type you like, including external types like `Vec<T>`. To this end, the orphan rule intuitively says “either the trait must be local or the self-type must be local”.
 > 
-> -- [Little Orphan Impls](http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/) by Niko Matsakis
+> -- [Little Orphan Impls](https://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/) by Niko Matsakis
 
 To check for coherence, the Rust compiler completes two separate but related checks:
 
@@ -17,7 +17,7 @@ To check for coherence, the Rust compiler completes two separate but related che
     - **compatible** - any semver compatible world
 # Resources About Coherence
 - [Coherence - talk by withoutboats](https://air.mozilla.org/rust-meetup-march-2017/)
-- [Little Orphan Impls](http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/)
+- [Little Orphan Impls](https://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/)
 - [RFC 1023 Rebalancing Coherence](https://rust-lang.github.io/rfcs/1023-rebalancing-coherence.html)
 - [Type classes: confluence, coherence and global uniqueness](http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/)
 ## Axioms & Properties of Coherence
@@ -44,7 +44,7 @@ There are several resources which can be used to figure out the orphan rules in
 - [RFC 1023: Rebalancing Coherence](https://rust-lang.github.io/rfcs/1023-rebalancing-coherence.html)
 - [*Trait Implementation Coherence*](https://doc.rust-lang.org/reference/items/implementations.html#trait-implementation-coherence) [in the](https://doc.rust-lang.org/reference/items/implementations.html#trait-implementation-coherence) [*Rust Reference*](https://doc.rust-lang.org/reference/items/implementations.html#trait-implementation-coherence)
 - [E0210: A violation of the orphan rules in the](https://doc.rust-lang.org/error-index.html#E0210) [*Rust Error Index*](https://doc.rust-lang.org/error-index.html#E0210)
-- [*Little Orphan Impls*](http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/) [by Niko Matsakis](http://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/)
+- [*Little Orphan Impls*](https://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/) [by Niko Matsakis](https://smallcultfollowing.com/babysteps/blog/2015/01/14/little-orphan-impls/)
 
 Of all of these, RFC 1023 is probably considered the most authoritative source on the orphan rules. The orphan rules as proposed in that RFC are as follows:
 
@@ -168,7 +168,7 @@ The conclusion from all of this is that it is perfectly safe to rule out impls t
 
 ## Discussion: Modelling the Overlap Check
 
-[Aaron’s excellent blog post](http://aturon.github.io/blog/2017/04/24/negative-chalk/) talks about this exact problem from the point of view of negative reasoning. It also describes a potential solution which we will apply here to solve our problem.
+[Aaron’s excellent blog post](https://aturon.github.io/blog/2017/04/24/negative-chalk/) talks about this exact problem from the point of view of negative reasoning. It also describes a potential solution which we will apply here to solve our problem.
 
 The **compatible modality** (`compat` in Aaron’s blog post) is necessary because we don’t always want to assume that all compatible impls exist. In particular, there are certain phases of compilation (e.g. trans) where the closed-world assumption is entirely necessary and sufficient.
 

book/src/clauses/coherence.md

@@ -298,5 +298,5 @@ more answers later on.
   for negative reasoning, but not how the SLG solver does it
 
 [readme]: https://github.com/rust-lang/chalk/blob/239e4ae4e69b2785b5f99e0f2b41fc16b0b4e65e/chalk-engine/src/README.md
-[slg-blog]: http://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/
+[slg-blog]: https://smallcultfollowing.com/babysteps/blog/2018/01/31/an-on-demand-slg-solver-for-chalk/
 [negative-reasoning-blog]: https://aturon.github.io/blog/2017/04/24/negative-chalk/

book/src/engine/slg.md

@@ -7,10 +7,10 @@ actually implement this? That's where the [`SearchGraph`] comes into play.
 [cycles]: ./inductive_cycles.md
 [coinduction]: ./coinduction.md
 [stack]: ./stack.md
-[`SearchGraph`]: http://rust-lang.github.io/chalk/chalk_recursive/search_graph/struct.SearchGraph.html
-[`DepthFirstNumber`]: http://rust-lang.github.io/chalk/chalk_recursive/search_graph/struct.DepthFirstNumber.html
-[`Node`]: http://rust-lang.github.io/chalk/chalk_recursive/search_graph/struct.Node.html
-[`stack_depth`]: http://rust-lang.github.io/chalk/chalk_recursive/search_graph/struct.Node.html#structfield.stack_depth
+[`SearchGraph`]: https://rust-lang.github.io/chalk/chalk_recursive/search_graph/struct.SearchGraph.html
+[`DepthFirstNumber`]: https://rust-lang.github.io/chalk/chalk_recursive/search_graph/struct.DepthFirstNumber.html
+[`Node`]: https://rust-lang.github.io/chalk/chalk_recursive/search_graph/struct.Node.html
+[`stack_depth`]: https://rust-lang.github.io/chalk/chalk_recursive/search_graph/struct.Node.html#structfield.stack_depth
 
 The role of the [`SearchGraph`] is to store information about each goal that we
 are currently solving. Typically, these are goals on the stack -- but other
@@ -183,7 +183,7 @@ recursively invoking some goal G2 that is in the search graph but *not* present
 on the stack, then we update the current [`Minimums`] with the values stored in
 the search graph.
 
-[`Minimums`]: http://rust-lang.github.io/chalk/chalk_recursive/struct.Minimums.html
+[`Minimums`]: https://rust-lang.github.io/chalk/chalk_recursive/struct.Minimums.html
 
 ## Removing nodes from the graph
 

book/src/recursive/search_graph.md

@@ -5,13 +5,13 @@ what it sounds like: a stack that stores each thing that the recursive solver is
 solving. Initially, it contains only one item, the root goal that was given by
 the user.
 
-[`Stack`]: http://rust-lang.github.io/chalk/chalk_recursive/stack/struct.Stack.html
+[`Stack`]: https://rust-lang.github.io/chalk/chalk_recursive/stack/struct.Stack.html
 
 Each frame on the stack has an associated [`StackDepth`], which is basically an
 index that increases (so 0 is the top of the stack, 1 is the next thing pushed,
 etc).
 
-[`StackDepth`]: http://rust-lang.github.io/chalk/chalk_recursive/stack/struct.StackDepth.html
+[`StackDepth`]: https://rust-lang.github.io/chalk/chalk_recursive/stack/struct.StackDepth.html
 
 ## How the recursive solver works at the highest level
 
@@ -74,4 +74,4 @@ detect a cycle by checking in the [search graph] to see whether G has an associa
 to learn more about that).
 
 [search graph]: ./search_graph.md
-[`cycle`]: http://rust-lang.github.io/chalk/chalk_recursive/stack/struct.StackEntry.html#structfield.cycle
+[`cycle`]: https://rust-lang.github.io/chalk/chalk_recursive/stack/struct.StackEntry.html#structfield.cycle

book/src/recursive/stack.md

@@ -5,7 +5,7 @@ chalk-ir and make a copy of it, possibly making small substitutions or
 alterations along the way. Folding also allows copying a term from one
 interner to another.
 
-[`Fold`]: http://rust-lang.github.io/chalk/chalk_ir/fold/trait.Fold.html
+[`Fold`]: https://rust-lang.github.io/chalk/chalk_ir/fold/trait.Fold.html
 
 To use the [`Fold`] trait, one invokes the [`Fold::fold_with`] method, supplying some
 "folder" as well as the number of "in scope binders" for that term (typically `0`
@@ -15,14 +15,14 @@ to start):
 let output_ty = input_ty.fold_with(&mut folder, 0);
 ```
 
-[`Fold::fold_with`]: http://rust-lang.github.io/chalk/chalk_ir/fold/trait.Fold.html#tymethod.fold_with
+[`Fold::fold_with`]: https://rust-lang.github.io/chalk/chalk_ir/fold/trait.Fold.html#tymethod.fold_with
 
 The folder is some instance of the [`Folder`] trait. This trait
 defines a few key callbacks that allow you to substitute different
 values as the fold proceeds. For example, when a type is folded, the
 folder can substitute a new type in its place.
 
-[`Folder`]: http://rust-lang.github.io/chalk/chalk_ir/fold/trait.Folder.html
+[`Folder`]: https://rust-lang.github.io/chalk/chalk_ir/fold/trait.Folder.html
 
 ## Uses for folders
 
@@ -69,7 +69,7 @@ XXX explain with examples and in more detail
 The `Fold` trait defines a [`Result`] associated type, indicating the
 type that will result from folding.
 
-[`Result`]: http://rust-lang.github.io/chalk/chalk_ir/fold/trait.Fold.html#associatedtype.Result
+[`Result`]: https://rust-lang.github.io/chalk/chalk_ir/fold/trait.Fold.html#associatedtype.Result
 
 ## When to implement the Fold and SuperFold traits
 

book/src/types/operations/fold.md

@@ -2,7 +2,7 @@
 
 Most everything in the IR is parameterized by the [`Interner`] trait:
 
-[`Interner`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
+[`Interner`]: https://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
 
 ```rust,ignore
 trait Interner: Copy + Clone + Debug + Eq + Ord {
@@ -25,17 +25,17 @@ done via an "indirection" strategy. We'll explain that strategy here
 in terms of [`Ty`] and [`TyKind`], the two types used to represent
 Rust types, but the same pattern is repeated for many other things.
 
-[`Interner`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
-[`Ty`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
-[`TyKind`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html
+[`Interner`]: https://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
+[`Ty`]: https://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
+[`TyKind`]: https://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html
 
 Types are represented by a [`Ty<I>`] type and the [`TyKind<I>`] enum.
 There is no *direct* connection between them. The link is rather made
 by the [`Interner`] trait, via the [`InternedTy`] associated type:
 
-[`Ty<I>`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
-[`TyKind<I>`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html
-[`InternedTy`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#associatedtype.InternedType
+[`Ty<I>`]: https://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
+[`TyKind<I>`]: https://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html
+[`InternedTy`]: https://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#associatedtype.InternedType
 
 ```rust,ignore
 struct Ty<I: Interner>(I::InternedTy);
@@ -45,8 +45,8 @@ enum TyKind<I: Interner> { .. }
 The way this works is that the [`Interner`] trait has an associated
 type [`InternedTy`] and two related methods, [`intern_ty`] and [`ty_data`]:
 
-[`intern_ty`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#tymethod.intern_ty
-[`ty_data`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#tymethod.ty_data
+[`intern_ty`]: https://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#tymethod.intern_ty
+[`ty_data`]: https://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html#tymethod.ty_data
 
 ```rust,ignore
 trait Interner {

book/src/types/role_of_interner.md

@@ -6,10 +6,10 @@ what sort of type you have, you invoke the [`kind`] method, which
 returns a [`TyKind`]. As described earlier, the actual in-memory
 representation of types is controlled by the [`Interner`] trait.
 
-[`Interner`]: http://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
-[`Ty`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
-[`TyKind`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html
-[`kind`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html#method.kind
+[`Interner`]: https://rust-lang.github.io/chalk/chalk_ir/interner/trait.Interner.html
+[`Ty`]: https://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html
+[`TyKind`]: https://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html
+[`kind`]: https://rust-lang.github.io/chalk/chalk_ir/struct.Ty.html#method.kind
 
 ## The `TyKind` variants and how they map to Rust syntax
 

book/src/types/rust_types.md

@@ -21,7 +21,7 @@ impl<I: Interner> InferenceTable<I> {
     /// negation-as-failure paper [1], where negative goals are only
     /// permitted if they contain no free (existential) variables.
     ///
-    /// [1] http://www.doc.ic.ac.uk/~klc/NegAsFailure.pdf
+    /// [1] https://www.doc.ic.ac.uk/~klc/NegAsFailure.pdf
     ///
     /// Restricting free existential variables is done because the
     /// semantics of such queries is not what you expect: it basically