Remove extra whitespace in the spec.

And ensure there is a single EOL at EOF.

Author: sjrd

docs/_spec/01-lexical-syntax.md

@@ -448,7 +448,7 @@ Inside an interpolated string none of the usual escape characters are interprete
 Note that the sequence `\"` does not close a normal string literal (enclosed in single quotes).
 
 There are three forms of dollar sign escape.
-The most general form encloses an expression in `${` and `}`, i.e. `${expr}`. 
+The most general form encloses an expression in `${` and `}`, i.e. `${expr}`.
 The expression enclosed in the braces that follow the leading `$` character is of syntactical category BlockExpr.
 Hence, it can contain multiple statements, and newlines are significant.
 Single ‘$’-signs are not permitted in isolation in an interpolated string.

docs/_spec/03-types.md

@@ -45,7 +45,7 @@ Non-value types capture properties of identifiers that [are not values](#non-val
 For example, a [type constructor](#type-constructors) does not directly specify a type of values.
 However, when a type constructor is applied to the correct type arguments, it yields a proper type, which may be a value type.
 
-Non-value types are expressed indirectly in Scala. 
+Non-value types are expressed indirectly in Scala.
 E.g., a method type is described by writing down a method signature, which in itself is not a real type, although it  gives rise to a corresponding [method type](#method-types).
 Type constructors are another example, as one can write `type Swap[m[_, _], a,b] = m[b, a]`, but there is no syntax to write the corresponding anonymous type function directly.
 
@@ -130,7 +130,7 @@ SimpleType  ::=  StableId
 ```
 
 A _type designator_ refers to a named value type.
-It can be simple or qualified. 
+It can be simple or qualified.
 All such type designators are shorthands for type projections.
 
 Specifically, the unqualified type name ´t´ where ´t´ is bound in some class, object, or package ´C´ is taken as a shorthand for
@@ -306,14 +306,14 @@ RefineStat      ::=  Dcl
                   |
 ```
 
-A _compound type_ ´T_1´ `with` ... `with` ´T_n \\{ R \\}´ represents objects with members as given in the component types ´T_1, ..., T_n´ and the refinement ´\\{ R \\}´. 
+A _compound type_ ´T_1´ `with` ... `with` ´T_n \\{ R \\}´ represents objects with members as given in the component types ´T_1, ..., T_n´ and the refinement ´\\{ R \\}´.
 A refinement ´\\{ R \\}´ contains declarations and type definitions.
 If a declaration or definition overrides a declaration or definition in one of the component types ´T_1, ..., T_n´, the usual rules for [overriding](05-classes-and-objects.html#overriding) apply; otherwise the declaration or definition is said to be “structural” [^2].
 
 [^2]: A reference to a structurally defined member (method call or access to a value or variable) may generate binary code that is significantly slower than an equivalent code to a non-structural member.
 
-Within a method declaration in a structural refinement, the type of any value parameter may only refer to type parameters or abstract types that are contained inside the refinement. 
-That is, it must refer either to a type parameter of the method itself, or to a type definition within the refinement. 
+Within a method declaration in a structural refinement, the type of any value parameter may only refer to type parameters or abstract types that are contained inside the refinement.
+That is, it must refer either to a type parameter of the method itself, or to a type definition within the refinement.
 This restriction does not apply to the method's result type.
 
 If no refinement is given, the empty refinement is implicitly added, i.e. ´T_1´ `with` ... `with` ´T_n´ is a shorthand for ´T_1´ `with` ... `with` ´T_n \\{\\}´.
@@ -382,7 +382,7 @@ Function types associate to the right, e.g. ´S \Rightarrow T \Rightarrow R´ is
 Function types are [covariant](04-basic-declarations-and-definitions.md#variance-annotations) in their result type and [contravariant](04-basic-declarations-and-definitions.md#variance-annotations) in their argument types.
 
 Function types are shorthands for class types that define an `apply` method.
-Specifically, the ´n´-ary function type ´(T_1, ..., T_n) \Rightarrow R´ is a shorthand for the class type `Function´_n´[´T_1´, ..., ´T_n´, ´R´]`. 
+Specifically, the ´n´-ary function type ´(T_1, ..., T_n) \Rightarrow R´ is a shorthand for the class type `Function´_n´[´T_1´, ..., ´T_n´, ´R´]`.
 In particular ´() \Rightarrow R´ is a shorthand for class type `Function´_0´[´R´]`.
 
 Such class types behave as if they were instances of the following trait:
@@ -396,7 +396,7 @@ Their exact supertype and implementation can be consulted in the [function class
 
 ## Non-Value Types
 
-The types explained in the following do not denote sets of values, nor do they appear explicitly in programs. 
+The types explained in the following do not denote sets of values, nor do they appear explicitly in programs.
 They are introduced in this report as the internal types of defined identifiers.
 
 ### Method Types

docs/_spec/04-basic-declarations-and-definitions.md

@@ -79,7 +79,7 @@ final val x = e
 ```
 
 where `e` is a [constant expression](06-expressions.html#constant-expressions).
-The `final` modifier must be present and no type annotation may be given. 
+The `final` modifier must be present and no type annotation may be given.
 References to the constant value `x` are themselves treated as constant expressions; in the generated code they are replaced by the definition's right-hand side `e`.
 
 Value definitions can alternatively have a [pattern](08-pattern-matching.html#patterns) as left-hand side.
@@ -311,7 +311,7 @@ TypeParam        ::= (id | ‘_’) [TypeParamClause] [‘>:’ Type] [‘<:’
 Type parameters appear in type definitions, class definitions, and method definitions.
 In this section we consider only type parameter definitions with lower bounds `>: ´L´` and upper bounds `<: ´U´` whereas a discussion of context bounds `: ´U´` and view bounds `<% ´U´` is deferred to [here](07-implicits.html#context-bounds-and-view-bounds).
 
-The most general form of a proper type parameter is 
+The most general form of a proper type parameter is
 `´@a_1 ... @a_n´ ´\pm´ ´t´ >: ´L´ <: ´U´`.
 Here, ´L´, and ´U´ are lower and upper bounds that constrain possible type arguments for the parameter.
 It is a compile-time error if ´L´ does not conform to ´U´.

docs/_spec/05-classes-and-objects.md

@@ -538,7 +538,7 @@ These are defined by constructor definitions of the form `def this(´\mathit{ps}
 Such a definition introduces an additional constructor for the enclosing class, with parameters as given in the formal parameter lists ´\mathit{ps}_1 , ..., \mathit{ps}_n´, and whose evaluation is defined by the constructor expression ´e´.
 The scope of each formal parameter is the subsequent parameter sections and the constructor expression ´e´.
 A constructor expression is either a self constructor invocation `this(´\mathit{args}_1´)...(´\mathit{args}_n´)` or a block which begins with a self constructor invocation.
-The self constructor invocation must construct a generic instance of the class. 
+The self constructor invocation must construct a generic instance of the class.
 I.e. if the class in question has name ´C´ and type parameters `[´\mathit{tps}\,´]`, then a self constructor invocation must generate an instance of `´C´[´\mathit{tps}\,´]`; it is not permitted to instantiate formal type parameters.
 
 The signature and the self constructor invocation of a constructor definition are type-checked and evaluated in the scope which is in effect at the point of the enclosing class definition, augmented by any type parameters of the enclosing class.

docs/_spec/06-expressions.md

@@ -713,7 +713,7 @@ Generator      ::=  [‘case’] Pattern1 ‘<-’ Expr {[semi] Guard | semi Pat
 Guard          ::=  ‘if’ PostfixExpr
 ```
 
-A _for loop_ `for (´\mathit{enums}\,´) ´e´` executes expression ´e´ for each binding generated by the enumerators ´\mathit{enums}´. 
+A _for loop_ `for (´\mathit{enums}\,´) ´e´` executes expression ´e´ for each binding generated by the enumerators ´\mathit{enums}´.
 A _for comprehension_ `for (´\mathit{enums}\,´) yield ´e´` evaluates expression ´e´ for each binding generated by the enumerators ´\mathit{enums}´ and collects the results.
 An enumerator sequence always starts with a generator; this can be followed by further generators, value definitions, or guards.
 

docs/_spec/08-pattern-matching.md

@@ -113,10 +113,10 @@ Taking XML as an example
 implicit class XMLinterpolation(s: StringContext) = {
     object xml {
         def apply(exprs: Any*) =
-            // parse ‘s’ and build an XML tree with ‘exprs’ 
+            // parse ‘s’ and build an XML tree with ‘exprs’
             //in the holes
         def unapplySeq(xml: Node): Option[Seq[Node]] =
-          // match `s’ against `xml’ tree and produce 
+          // match `s’ against `xml’ tree and produce
           //subtrees in holes
     }
 }
@@ -500,7 +500,7 @@ Each case consists of a (possibly guarded) pattern ´p_i´ and a block ´b_i´.
 Each ´p_i´ might be complemented by a guard `if ´e´` where ´e´ is a boolean expression.
 The scope of the pattern variables in ´p_i´ comprises the pattern's guard and the corresponding block ´b_i´.
 
-Let ´T´ be the type of the selector expression ´e´ and let ´a_1, ..., a_m´ be the type parameters of all methods enclosing the pattern matching expression.  
+Let ´T´ be the type of the selector expression ´e´ and let ´a_1, ..., a_m´ be the type parameters of all methods enclosing the pattern matching expression.
 For every ´a_i´, let ´L_i´ be its lower bound and ´U_i´ be its higher bound.
 Every pattern ´p \in \{p_1,, ..., p_n\}´ can be typed in two ways.
 First, it is attempted to type ´p´ with ´T´ as its expected type.
@@ -566,7 +566,7 @@ def eval[T](t: Term[T]): T = t match {
 
 Note that the evaluator makes crucial use of the fact that type parameters of enclosing methods can acquire new bounds through pattern matching.
 
-For instance, the type of the pattern in the second case, `Succ(u)`, is `Int`. 
+For instance, the type of the pattern in the second case, `Succ(u)`, is `Int`.
 It conforms to the selector type `T` only if we assume an upper and lower bound of `Int` for `T`.
 Under the assumption `Int <: T <: Int` we can also verify that the type right hand side of the second case, `Int` conforms to its expected type, `T`.
 

docs/_spec/11-annotations.md

@@ -109,7 +109,7 @@ trait Function0[@specialized(Unit, Int, Double) T] {
 ```
 Whenever the static type of an expression matches a specialized variant of a definition, the compiler will instead use the specialized version.
 See the [specialization sid](https://docs.scala-lang.org/sips/scala-specialization.html) for more details of the implementation.
-    
+
 
 ## User-defined Annotations
 

docs/_spec/A1-deprecated.md

@@ -18,4 +18,4 @@ scalac Test.scala
   |                         For now, you can also `import language.deprecated.symbolLiterals` to accept
   |                         the idiom, but this possibility might no longer be available in the future.
 1 error found
-```
+```

docs/_spec/A2-scala-2-compatibility.md

@@ -32,4 +32,4 @@ def f(): Unit = { ... }
 Scala 3 accepts the old syntax under the `-source:3.0-migration` option.
 If the `-migration` option is set, it can even rewrite old syntax to new.
 The [Scalafix](https://scalacenter.github.io/scalafix/) tool also
-can rewrite procedure syntax to make it Scala 3 compatible.
+can rewrite procedure syntax to make it Scala 3 compatible.

docs/_spec/A3-to-be-deprecated.md

@@ -1,4 +1,4 @@
 This is a simple list of feature that are not deprecated yet, but will be in the future.
 They should emit warnings or errors only when using the `-source:future` compiler flag.
 
-- [private[this] and protected[this]](../_docs/reference/dropped-features/this-qualifier.md)
+- [private[this] and protected[this]](../_docs/reference/dropped-features/this-qualifier.md)