fix formatting

Author: lrytz

news/_posts/2016-04-11-release-notes-2.12.0-M4.md

@@ -60,34 +60,30 @@ The work on the new optimizer is still ongoing.  You can track it in the [scala-
 #### SAM types
 As of [#4971](https://github.com/scala/scala/pull/4971), we treat Single Abstract Method types in the same way as our built-in FunctionN classes. This means overloading resolution has more contenders to choose from, making type inference less effective. Here's an example:
 
-```scala
-class C[V] {
-  def sort(cmp: java.util.Comparator[V]): C[V] = ???
-  def sort(cmp: (V, V) => Int): C[V] = sort(
-    new java.util.Comparator[V] {
-      def compare(a: V, b: V): Int = cmp(a, b)
-    })
-}
-
-(new C[Int]) sort (_ - _) // error
-(new C[Int]) sort ((_ - _): java.util.Comparator[Int]) // ok
-(new C[Int]) sort ((a: Int, b: Int) => a - b)  // ok
-```
+    class C[V] {
+      def sort(cmp: java.util.Comparator[V]): C[V] = ???
+      def sort(cmp: (V, V) => Int): C[V] = sort(
+        new java.util.Comparator[V] {
+          def compare(a: V, b: V): Int = cmp(a, b)
+        })
+    }
+
+    (new C[Int]) sort (_ - _) // error
+    (new C[Int]) sort ((_ - _): java.util.Comparator[Int]) // ok
+    (new C[Int]) sort ((a: Int, b: Int) => a - b)  // ok
 
 The first attempt fails because the type checker cannot infer the types for `_ - _`'s arguments anymore.
 Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments the methods are applied to. When a function is passed as an argument to an overloaded method, we do this by considering the "shape" of the function (essentially, its arity). Now that `Comparator[?]` and `(?, ?) => ?` are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the `Function2` overload).
 
 Finally, implicit conversion of SAM types to Function types won't kick in anymore, since the compiler does this conversion itself first:
 
-```scala
-trait MySam { def apply(x: Int): String }
+    trait MySam { def apply(x: Int): String }
 
-implicit def unused(fun: Int => String): MySam 
-  = new MySam { def apply(x: Int) = fun(x) }
+    implicit def unused(fun: Int => String): MySam
+      = new MySam { def apply(x: Int) = fun(x) }
 
-// uses sam conversion, not the `unused` implicit
-val sammy: MySam = _.toString
-```
+    // uses sam conversion, not the `unused` implicit
+    val sammy: MySam = _.toString
 
 #### Changed syntax trees (affects macro and compiler plugin authors)
 

news/_posts/2016-06-29-release-notes-2.12.0-M5.md

@@ -9,6 +9,7 @@ We are happy to announce the availability of Scala 2.12.0-M5!
 Notable changes in M5
 ([see here](https://github.com/scala/scala/pulls?utf8=%E2%9C%93&q=milestone%3A2.12.0-M5%20label%3Arelease-notes)
 for a more extensive list):
+
   - [#5251](https://github.com/scala/scala/pull/5251): concrete trait methods are compiled to a
     static method (in the interface classfile) containing the actual implementation, and a default
     method forwards that to the static one.
@@ -82,34 +83,30 @@ The work on the new optimizer is still ongoing.  You can track it in the [scala-
 #### SAM types
 As of [#4971](https://github.com/scala/scala/pull/4971), we treat Single Abstract Method types in the same way as our built-in FunctionN classes. This means overloading resolution has more contenders to choose from, making type inference less effective. Here's an example:
 
-```scala
-class C[V] {
-  def sort(cmp: java.util.Comparator[V]): C[V] = ???
-  def sort(cmp: (V, V) => Int): C[V] = sort(
-    new java.util.Comparator[V] {
-      def compare(a: V, b: V): Int = cmp(a, b)
-    })
-}
+    class C[V] {
+      def sort(cmp: java.util.Comparator[V]): C[V] = ???
+      def sort(cmp: (V, V) => Int): C[V] = sort(
+        new java.util.Comparator[V] {
+          def compare(a: V, b: V): Int = cmp(a, b)
+        })
+    }
 
-(new C[Int]) sort (_ - _) // error
-(new C[Int]) sort ((_ - _): java.util.Comparator[Int]) // ok
-(new C[Int]) sort ((a: Int, b: Int) => a - b)  // ok
-```
+    (new C[Int]) sort (_ - _) // error
+    (new C[Int]) sort ((_ - _): java.util.Comparator[Int]) // ok
+    (new C[Int]) sort ((a: Int, b: Int) => a - b)  // ok
 
 The first attempt fails because the type checker cannot infer the types for `_ - _`'s arguments anymore.
 Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments the methods are applied to. When a function is passed as an argument to an overloaded method, we do this by considering the "shape" of the function (essentially, its arity). Now that `Comparator[?]` and `(?, ?) => ?` are both considered functions of arity two, our clever scheme breaks down and the programmer must either select an overload (second application) or make the argument types explicit (last application, which resolves to the `Function2` overload).
 
 Finally, implicit conversion of SAM types to Function types won't kick in anymore, since the compiler does this conversion itself first:
 
-```scala
-trait MySam { def apply(x: Int): String }
+    trait MySam { def apply(x: Int): String }
 
-implicit def unused(fun: Int => String): MySam
-  = new MySam { def apply(x: Int) = fun(x) }
+    implicit def unused(fun: Int => String): MySam
+      = new MySam { def apply(x: Int) = fun(x) }
 
-// uses sam conversion, not the `unused` implicit
-val sammy: MySam = _.toString
-```
+    // uses sam conversion, not the `unused` implicit
+    val sammy: MySam = _.toString
 
 #### Changed syntax trees (affects macro and compiler plugin authors)