Use base.url for '/' root relative links

_includes/books.html

@@ -5,7 +5,7 @@
       <div class="book-item-header">
         <a href="{{book.link}}">
           <div class="content-img-boook">
-            <img src="{{book.image}}" alt="{{book.title}}">
+            <img src="{{site.baseurl}}{{book.image}}" alt="{{book.title}}">
           </div>
           <h3>{{book.title}}</h3>
         </a>

_includes/footer.html

@@ -5,7 +5,7 @@
           <ul class="{{item.class}}">
             <li><h3>{{item.title}}</h3></li>
             {% for link in item.links %}
-              <li><a href="{{link.url}}">{{link.title}}</a></li>
+              <li><a href="{% if link.url contains '://' %}{{link.url}}{% else %}{{site.baseurl}}{{link.url}}{% endif %}">{{link.title}}</a></li>
             {% endfor %}
           </ul>
         {% endfor %}

_includes/masthead-documentation.html

@@ -6,7 +6,7 @@
           <div class="section">
             <h2 class="frontpage">{{ section.title }}</h2>
             {% for link in section.links %}
-  					<a href="{{link.link}}" class="doc-item">
+  					<a href="{% if link.link contains '://' %}{{link.link}}{% else %}{{site.baseurl}}{{link.link}}{% endif %}" class="doc-item">
   						<div class="doc-item-header">
   							<i class="{{link.icon}}"></i>
   							<h5>{{link.title}}</h5>
@@ -22,7 +22,7 @@ <h5>{{link.title}}</h5>
               <span class="heading">More Resources: </span>
               <ul>
               {% for resource in section.more-resources %}
-                <li><a href="{{ resource.url }}">{{ resource.title }}</a></li>
+                <li><a href="{{ site.baseurl }}{{ resource.url }}">{{ resource.title }}</a></li>
               {% endfor %}
               </ul>
             {% endif %}

_includes/navbar-inner.html

@@ -10,7 +10,7 @@
       <ul class="navigation-menu">
         {% for navItem in site.data.nav-header %}
             <li class="navigation-menu-item">
-              <a href="{{navItem.url}}/" {% if page.url contains navItem.url %}class="active"{% endif %}>{{navItem.title}}</a>
+              <a href="{% if navItem.url contains '://' %}{{navItem.url}}{% else %}{{site.baseurl}}{{navItem.url}}{% endif %}" {% if page.url contains navItem.url %}class="active"{% endif %}>{{navItem.title}}</a>
             </li>
         {% endfor %}
       </ul>
@@ -29,12 +29,12 @@
       <ul class="navigation-menu">
         {% for navItem in site.data.doc-nav-header %}
             <li class="navigation-menu-item">
-              <a href="{{navItem.url}}" id="{{ navItem.title | downcase | strip }}" {% if page.url contains navItem.url %}class="active"{% endif %}>{{navItem.title}}</a>
+              <a href="{% if navItem.url contains '://' or navItem.url == '#'  %}{{navItem.url}}{% else %}{{site.baseurl}}{{navItem.url}}{% endif %}" id="{{ navItem.title | downcase | strip }}" {% if page.url contains navItem.url %}class="active"{% endif %}>{{navItem.title}}</a>
                 {% if navItem.submenu %}
                 <ul class="navigation-dropdown">
                 {% for subItem in navItem.submenu %}
                   <li>
-                    <a href="{{ subItem.url }}">{{ subItem.title }}</a>
+                    <a href="{% if subItem.url contains '://' %}{{ subItem.url }}{% else %}{{ site.baseurl }}{{ subItem.url }}{% endif %}">{{ subItem.title }}</a>
                   </li>
                 {% endfor %}
                 </ul>
@@ -49,7 +49,7 @@
           <ul class="navigation-submenu" id="{{ navItem.title | downcase | strip }}" style="display: none;">
             {% for subItem in navItem.submenu %}
               <li>
-                <a href="{{ subItem.url }}">{{ subItem.title }}</a>
+                <a href="{% if subItem.url contains '://' %}{{subItem.url}}{% else %}{{site.baseurl}}{{subItem.url}}{% endif %}">{{ subItem.title }}</a>
               </li>
             {% endfor %}
           </ul>
@@ -58,7 +58,7 @@
       <ul class="navigation-submenu ellipsis-menu" style="display: none;">
         {% for navItem in site.data.doc-nav-header %}
           {% if forloop.index > 3 %}
-            <li><a href="{{ navItem.url }}">{{ navItem.title }}</a></li>
+            <li><a href="{% if navItem.url contains '://' %}{{navItem.url}}{% else %}{{site.baseurl}}{{navItem.url}}{% endif %}">{{ navItem.title }}</a></li>
           {% endif %}
         {% endfor %}
       </ul>

_includes/sidebar-toc-multipage-overview.html

@@ -25,7 +25,7 @@ <h5 class="contents">Contents</h5>
 
       {% if page.languages %}
         <ul id="available-languages" style="display: none;">
-          <li><a href="{{ page.url }}">English</a></li>
+          <li><a href="{{ site.baseurl }}{{ page.url }}">English</a></li>
           {% for l in page.languages %}
             {% capture intermediate %}{{ page.url | remove_first: l }}{% endcapture %}
             {% capture rootTutorialURL %}{{ intermediate | remove_first: '/' }}{% endcapture %}

_includes/sidebar-toc-singlepage-overview.html

@@ -5,7 +5,7 @@ <h5 class="contents">Contents</h5>
       <div id="toc"></div>
       {% if page.languages %}
         <ul id="available-languages" style="display: none;">
-          <li><a href="{{ page.url }}">English</a></li>
+          <li><a href="{{ site.baseurl }}{{ page.url }}">English</a></li>
           {% for l in page.languages %}
             {% capture intermediate %}{{ page.url | remove_first: l }}{% endcapture %}
             {% capture rootTutorialURL %}{{ intermediate | remove_first: '/' }}{% endcapture %}

_includes/sidebar-toc-tour-overview.html

@@ -33,7 +33,7 @@ <h5 class="contents">Contents</h5>
         </ul>
       {% elsif site.data.translations.tour.languages != empty  %}
         <ul id="available-languages" style="display: none;">
-          <li><a href="{{ page.url }}">English</a></li>
+          <li><a href="{{ site.baseurl }}{{ page.url }}">English</a></li>
           {% for l in site.data.translations.tour.languages %}
             {% capture intermediate %}{{ page.url | remove_first: l }}{% endcapture %}
             {% capture rootTutorialURL %}{{ intermediate | remove_first: '/' }}{% endcapture %}

_layouts/cheatsheet.html

@@ -9,7 +9,7 @@
 				{{content}}
         {% if page.languages %}
           <ul id="available-languages" style="display: none;">
-            <li><a href="{{ page.url }}">English</a></li>
+            <li><a href="{{site.baseurl}}{{ page.url }}">English</a></li>
             {% for l in page.languages %}
               {% capture intermediate %}{{ page.url | remove_first: l }}{% endcapture %}
               {% capture rootTutorialURL %}{{ intermediate | remove_first: '/' }}{% endcapture %}

_overviews/FAQ/index.md

@@ -16,7 +16,7 @@ provided by Daniel Sobral, adapted from his StackOverflow posts.
 <ul>
 {% for overview in overviews %}
   {% if overview.partof == "FAQ" %}
-    <li><a href="{{ overview.url }}">{{ overview.title }}</a></li>
+    <li><a href="{{ site.baseurl }}{{ overview.url }}">{{ overview.title }}</a></li>
   {% endif %}
 {% endfor %}
 </ul>

_overviews/cheatsheets/index.md

@@ -320,7 +320,7 @@ Some(3) match {
     </tr>
     <tr>
       <td><code class="highlighter-rouge">trait T { ... }</code><br /><code class="highlighter-rouge">class C extends T { ... }</code><br /><code class="highlighter-rouge">class C extends D with T { ... }</code></td>
-      <td>traits.<br />interfaces-with-implementation. no constructor params. <a href="/tutorials/tour/mixin-class-composition.html">mixin-able</a>.</td>
+      <td>traits.<br />interfaces-with-implementation. no constructor params. <a href="{{site.baseurl}}/tutorials/tour/mixin-class-composition.html">mixin-able</a>.</td>
     </tr>
     <tr>
       <td><code class="highlighter-rouge">trait T1; trait T2</code><br /><code class="highlighter-rouge">class C extends T1 with T2</code><br /><code class="highlighter-rouge">class C extends D with T1 with T2</code></td>

_overviews/collections/trait-traversable.md

@@ -35,7 +35,7 @@ The `foreach` method is meant to traverse all elements of the collection, and ap
 * **Folds** `foldLeft`, `foldRight`, `/:`, `:\`, `reduceLeft`, `reduceRight` which apply a binary operation to successive elements.
 * **Specific folds** `sum`, `product`, `min`, `max`, which work on collections of specific types (numeric or comparable).
 * **String** operations `mkString`, `addString`, `stringPrefix`, which give alternative ways of converting a collection to a string.
-* **View** operations, consisting of two overloaded variants of the `view` method. A view is a collection that's evaluated lazily. You'll learn more about views in [later](#Views).
+* **View** operations, consisting of two overloaded variants of the `view` method. A view is a collection that's evaluated lazily. You'll learn more about views in [later](views.html).
 
 ### Operations in Class Traversable ###
 

_overviews/macros/annotations.md

@@ -18,7 +18,7 @@ permalink: /overviews/macros/:title.html
 
 Macro annotations are only available with the macro paradise plugin (in Scala 2.10.x, 2.11.x and 2.12.x alike).
 Their inclusion in official Scala might happen in Scala 2.13, but there is no certainty about it yet.
-Follow the instructions at the ["Macro Paradise"](/overviews/macros/paradise.html) page to download and use our compiler plugin.
+Follow the instructions at the ["Macro Paradise"](paradise.html) page to download and use our compiler plugin.
 
 Note that macro paradise is needed both to compile and to expand macro annotations,
 which means that your users will have to also add macro paradise to their builds in order to use your macro annotations.
@@ -109,5 +109,5 @@ macro annotations are not an exceptions. During expansion we can have all the ty
 
 ## Blackbox vs whitebox
 
-Macro annotations must be [whitebox](/overviews/macros/blackbox-whitebox.html).
-If you declare a macro annotation as [blackbox](/overviews/macros/blackbox-whitebox.html), it will not work.
+Macro annotations must be [whitebox]({{ site.baseurl }}/overviews/macros/blackbox-whitebox.html).
+If you declare a macro annotation as [blackbox]({{ site.baseurl }}/overviews/macros/blackbox-whitebox.html), it will not work.

_overviews/macros/blackbox-whitebox.md

@@ -35,7 +35,7 @@ compehensibility.
 
 However sometimes def macros transcend the notion of "just a regular method". For example, it is possible for a macro expansion to yield an expression of a type that is more specific than the return type of a macro. In Scala 2.10, such expansion will retain its precise type as highlighted in the ["Static return type of Scala macros"](http://stackoverflow.com/questions/13669974/static-return-type-of-scala-macros) article at Stack Overflow.
 
-This curious feature provides additional flexibility, enabling [fake type providers](http://meta.plasm.us/posts/2013/07/11/fake-type-providers-part-2/), [extended vanilla materialization](/sips/pending/source-locations.html), [fundep materialization](/overviews/macros/implicits.html#fundep-materialization) and [extractor macros](https://github.com/scala/scala/commit/84a335916556cb0fe939d1c51f27d80d9cf980dc), but it also sacrifices clarity - both for humans and for machines.
+This curious feature provides additional flexibility, enabling [fake type providers](http://meta.plasm.us/posts/2013/07/11/fake-type-providers-part-2/), [extended vanilla materialization](/sips/pending/source-locations.html), [fundep materialization]({{ site.baseurl }}/overviews/macros/implicits.html#fundep-materialization) and [extractor macros](https://github.com/scala/scala/commit/84a335916556cb0fe939d1c51f27d80d9cf980dc), but it also sacrifices clarity - both for humans and for machines.
 
 To concretize the crucial distinction between macros that behave just like normal methods and macros that refine their return types, we introduce the notions of blackbox macros and whitebox macros. Macros that faithfully follow their type signatures are called **blackbox macros** as their implementations are irrelevant to understanding their behaviour (could be treated as black boxes). Macros that can't have precise signatures in Scala's type system are called **whitebox macros** (whitebox def macros do have signatures, but these signatures are only approximations).
 
@@ -50,8 +50,8 @@ We express the distinction by replacing `scala.reflect.macros.Context` with `sca
 Blackbox def macros are treated differently from def macros of Scala 2.10. The following restrictions are applied to them by the Scala typechecker:
 
 1. When an application of a blackbox macro expands into tree `x`, the expansion is wrapped into a type ascription `(x: T)`, where `T` is the declared return type of the blackbox macro with type arguments and path dependencies applied in consistency with the particular macro application being expanded. This invalidates blackbox macros as an implementation vehicle of [type providers](http://meta.plasm.us/posts/2013/07/11/fake-type-providers-part-2/).
-1. When an application of a blackbox macro still has undetermined type parameters after Scala's type inference algorithm has finished working, these type parameters are inferred forcedly, in exactly the same manner as type inference happens for normal methods. This makes it impossible for blackbox macros to influence type inference, prohibiting [fundep materialization](/overviews/macros/implicits.html#fundep-materialization).
-1. When an application of a blackbox macro is used as an implicit candidate, no expansion is performed until the macro is selected as the result of the implicit search. This makes it impossible to [dynamically calculate availability of implicit macros](/sips/rejected/source-locations.html).
+1. When an application of a blackbox macro still has undetermined type parameters after Scala's type inference algorithm has finished working, these type parameters are inferred forcedly, in exactly the same manner as type inference happens for normal methods. This makes it impossible for blackbox macros to influence type inference, prohibiting [fundep materialization]({{ site.baseurl }}/overviews/macros/implicits.html#fundep-materialization).
+1. When an application of a blackbox macro is used as an implicit candidate, no expansion is performed until the macro is selected as the result of the implicit search. This makes it impossible to [dynamically calculate availability of implicit macros]({{ site.baseurl }}/sips/rejected/source-locations.html).
 1. When an application of a blackbox macro is used as an extractor in a pattern match, it triggers an unconditional compiler error, preventing [customizations of pattern matching](https://github.com/paulp/scala/commit/84a335916556cb0fe939d1c51f27d80d9cf980dc) implemented with macros.
 
 Whitebox def macros work exactly like def macros used to work in Scala 2.10. No restrictions of any kind get applied, so everything that could be done with macros in 2.10 should be possible in 2.11 and 2.12.

_overviews/macros/bundles.md

@@ -27,7 +27,7 @@ following reasons:
 1. Being limited to functions makes modularizing complex macros awkward. It's quite typical to see macro logic concentrate in helper
 traits outside macro implementations, turning implementations into trivial wrappers, which just instantiate and call helpers.
 
-2. Moreover, since macro parameters are path-dependent on the macro context, [special incantations](/overviews/macros/overview.html#writing-bigger-macros) are required to wire implementations and helpers together.
+2. Moreover, since macro parameters are path-dependent on the macro context, [special incantations](overview.html#writing-bigger-macros) are required to wire implementations and helpers together.
 
 Macro bundles provide a solution to these problems by allowing macro implementations to be declared in classes that take
 `c: scala.reflect.macros.blackbox.Context` or `c: scala.reflect.macros.whitebox.Context` as their constructor parameters, relieving macro implementations from having
@@ -49,4 +49,4 @@ providing type arguments if necessary.
 
 ## Blackbox vs whitebox
 
-Macro bundles can be used to implement both [blackbox](/overviews/macros/blackbox-whitebox.html) and [whitebox](/overviews/macros/blackbox-whitebox.html) macros. Give the macro bundle constructor parameter the type of `scala.reflect.macros.blackbox.Context` to define a blackbox macro and  the type of `scala.reflect.macros.whitebox.Context` to define a whitebox macro.
+Macro bundles can be used to implement both [blackbox]({{ site.baseurl }}/overviews/macros/blackbox-whitebox.html) and [whitebox]({{ site.baseurl }}/overviews/macros/blackbox-whitebox.html) macros. Give the macro bundle constructor parameter the type of `scala.reflect.macros.blackbox.Context` to define a blackbox macro and  the type of `scala.reflect.macros.whitebox.Context` to define a whitebox macro.

_overviews/macros/changelog211.md

@@ -21,7 +21,7 @@ This document lists all major changes to reflection and macros during the develo
 
 ### Quasiquotes
 
-Quasiquotes is the single most impressive upgrade for reflection and macros in Scala 2.11.0. Implemented by Denys Shabalin, they have significantly simplified the life of Scala metaprogrammers around the globe. Visit [the dedicated documentation page](/overviews/quasiquotes/intro.html) to learn more about quasiquotes.
+Quasiquotes is the single most impressive upgrade for reflection and macros in Scala 2.11.0. Implemented by Denys Shabalin, they have significantly simplified the life of Scala metaprogrammers around the globe. Visit [the dedicated documentation page]({{ site.baseurl }}/overviews/quasiquotes/intro.html) to learn more about quasiquotes.
 
 ### New macro powers
 
@@ -53,7 +53,7 @@ Quasiquotes is the single most impressive upgrade for reflection and macros in S
 
 12) **[Introduction of Universe.internal and Context.internal](https://github.com/xeno-by/scala/commit/114c99691674873393223a11a9aa9168c3f41d77)**. Feedback from the users of the Scala 2.10.x reflection API has given us two important insights. First, certain functionality that we exposed was too low-level and were very out of place in the public API. Second, certain low-level functionality was very important in getting important macros operational. In order to somewhat resolve the tension created by these two development vectors, we've created internal subsections of the public APIs that are: a) clearly demarcated from the blessed parts of the reflection API, b) available to those who know what they are doing and want to implement practically important use cases that we want to support. Follow migration and compatibility notes in the bottom of the document to learn more.
 
-13) **[Thread safety for runtime reflection](http://docs.scala-lang.org/overviews/reflection/thread-safety.html)**. The most pressing problem in reflection for Scala 2.10.x was its thread unsafety. Attempts to use runtime reflection (e.g. type tags) from multiple threads resulted in weird crashes documented above. We believe to have fixed this problem in Scala 2.11.0-RC1 by introducing a number of locks in critical places of our implementation. On the one hand, the strategy we are using at the moment is sub-optimal in the sense that certain frequently used operations (such as `Symbol.typeSignature` or `TypeSymbol.typeParams`) are hidden behind a global lock, but we plan to optimize that in the future. On the other hand, most of the typical APIs (e.g. `Type.members` or `Type.<:<`) either use thread-local state or don't require synchronization at all, so it's definitely worth a try.
+13) **[Thread safety for runtime reflection]({{ site.baseurl }}/overviews/reflection/thread-safety.html)**. The most pressing problem in reflection for Scala 2.10.x was its thread unsafety. Attempts to use runtime reflection (e.g. type tags) from multiple threads resulted in weird crashes documented above. We believe to have fixed this problem in Scala 2.11.0-RC1 by introducing a number of locks in critical places of our implementation. On the one hand, the strategy we are using at the moment is sub-optimal in the sense that certain frequently used operations (such as `Symbol.typeSignature` or `TypeSymbol.typeParams`) are hidden behind a global lock, but we plan to optimize that in the future. On the other hand, most of the typical APIs (e.g. `Type.members` or `Type.<:<`) either use thread-local state or don't require synchronization at all, so it's definitely worth a try.
 
 14) **[Type.typeArgs](https://github.com/xeno-by/scala/commit/0f4e95574081bd9a945fb5b32d157a32af840cd3)**. It is now dead simple to obtain type arguments of a given type. What required a pattern match in Scala 2.10.x is now a simple method invocation. The `typeArgs` method is also joined by `typeParams`, `paramLists`, and `resultType`, making it very easy to perform common type inspection tasks.