fix #10138: trim trailing whitespace

Author: bishabosha

scala3doc/dotty-docs/docs/_layouts/base.html

@@ -28,4 +28,4 @@
     window.scrollTo(0, $(window.location.hash).offset().top - 90);
   }
 })
-</script>
+</script>

scala3doc/dotty-docs/docs/blog/_posts/2019-01-21-12th-dotty-milestone-release.md

@@ -221,4 +221,4 @@ to make sure that our regression suite includes your library.
 [@Blaisorblade]: https://github.com/Blaisorblade
 [@Duhemm]: https://github.com/Duhemm
 [@AleksanderBG]: https://github.com/AleksanderBG
-[@milessabin]: https://github.com/milessabin
+[@milessabin]: https://github.com/milessabin

scala3doc/dotty-docs/docs/docs/contributing/contribute-knowledge.md

@@ -9,4 +9,4 @@ If you know anything useful at all about Dotty, feel free to log this knowledge:
 - [📜Log the Knowledge](https://github.com/lampepfl/dotty-knowledge/issues/new)
 - [🎓More about Logging the Knowledge](https://github.com/lampepfl/dotty-knowledge/blob/master/README.md)
 
-In short, no need to make it pretty, particularly human-readable or give it a particular structure. Just dump the knowledge you have and we'll take it from there.
+In short, no need to make it pretty, particularly human-readable or give it a particular structure. Just dump the knowledge you have and we'll take it from there.

scala3doc/dotty-docs/docs/docs/contributing/procedures/release.md

@@ -152,4 +152,4 @@ git checkout master
 
 git commit -am 'Set baseVersion to 0.16.0'
 git push origin master
-```
+```

scala3doc/dotty-docs/docs/docs/contributing/testing.md

@@ -9,9 +9,9 @@ Running all tests in Dotty is as simple as:
 $ sbt test
 ```
 
-Specifically, `sbt test` runs all tests that do _not_ require a bootstrapped 
-compiler. In practice, this means that it runs all compilation tests meeting 
-this criterion, as well as all non-compiler tests. 
+Specifically, `sbt test` runs all tests that do _not_ require a bootstrapped
+compiler. In practice, this means that it runs all compilation tests meeting
+this criterion, as well as all non-compiler tests.
 
 The entire suite of tests can be run using the bootstrapped compiler as follows:
 

scala3doc/dotty-docs/docs/docs/reference/changed-features/pattern-matching.md

@@ -240,4 +240,4 @@ def foo(f: Foo) = f match {
 ```
 
 There are plans for further simplification, in particular to factor out *product
-match* and *name-based match* into a single type of extractor.
+match* and *name-based match* into a single type of extractor.

scala3doc/dotty-docs/docs/docs/reference/contextual/extension-methods.md

@@ -259,7 +259,7 @@ def extension_position(s: String)(ch: Char, n: Int): Int =
      extension (x: Double) def ** (exponent: Int): Double =
        require(exponent >= 0)
        if exponent == 0 then 1 else x * (x ** (exponent - 1))
-  
+
    import DoubleOps.{**, extension_**}
    assert(2.0 ** 3 == extension_**(2.0)(3))
    ```

scala3doc/dotty-docs/docs/docs/reference/dropped-features/macros.md

@@ -3,7 +3,7 @@ layout: doc-page
 title: Dropped: Scala 2 Macros
 ---
 
-The previous, experimental macro system has been dropped. Instead, there is a cleaner, more restricted system based on two complementary concepts: `inline` and `'{ ... }`/`${ ... }` code generation. 
+The previous, experimental macro system has been dropped. Instead, there is a cleaner, more restricted system based on two complementary concepts: `inline` and `'{ ... }`/`${ ... }` code generation.
 `'{ ... }` delays the compilation of the code and produces an object containing the code, dually `${ ... }` evaluates an expression which produces code and inserts it in the surrounding `${ ... }`.
 In this setting, a definition marked as inlined containing a `${ ... }` is a macro, the code inside the `${ ... }` is executed at compile-time and produces code in the form of `'{ ... }`.
 Additionally, the contents of code can be inspected and created with a more complex reflection API (TASTy Reflect) as an extension of `'{ ... }`/`${ ... }` framework.

scala3doc/dotty-docs/docs/docs/reference/features-classification.md

@@ -199,4 +199,4 @@ Some existing programs will break and, given the complex nature of type inferenc
 
 In our experience, macros and changes in type and implicit argument inference together cause the large majority of problems encountered when porting existing code to Scala 3. The latter source of problems could be addressed systematically by a tool that added all inferred types and implicit arguments to a Scala 2 source code file. Most likely such a tool would be implemented as a Scala 2 compiler plugin. The resulting code would have a greatly increased likelihood to compile under Scala 3, but would often be bulky to the point of being unreadable. A second part of the rewriting tool should then selectively and iteratively remove type and implicit annotations that were synthesized by the first part as long as they compile under Scala 3. This second part could be implemented as a program that invokes the Scala 3 compiler `dotc` programmatically.
 
-Several people have proposed such a tool for some time now. I believe it is time we find the will and the resources to actually implement it.
+Several people have proposed such a tool for some time now. I believe it is time we find the will and the resources to actually implement it.

scala3doc/dotty-docs/docs/docs/reference/metaprogramming/inline.md

@@ -268,10 +268,10 @@ val obj2 = choose(false) // static type is B
 // obj1.m() // compile-time error: `m` is not defined on `A`
 obj2.m()    // OK
 ```
-Here, the inline method `choose` returns an instance of either of the two types `A` or `B`. 
+Here, the inline method `choose` returns an instance of either of the two types `A` or `B`.
 If `choose` had not been declared to be `transparent`, the result
-of its expansion would always be of type `A`, even though the computed value might be of the subtype `B`. 
-The inline method is a "blackbox" in the sense that details of its implementation do not leak out. 
+of its expansion would always be of type `A`, even though the computed value might be of the subtype `B`.
+The inline method is a "blackbox" in the sense that details of its implementation do not leak out.
 But if a `transparent` modifier is given, the expansion is the type of the expanded body. If the argument `b`
 is `true`, that type is `A`, otherwise it is `B`. Consequently, calling `m` on `obj2`
 type-checks since `obj2` has the same type as the expansion of `choose(false)`, which is `B`.