spelling: to which methods are applied

Signed-off-by: Josh Soref <[email protected]>

Author: jsoref

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

@@ -73,7 +73,7 @@ As of [#4971](https://github.com/scala/scala/pull/4971), we treat Single Abstrac
     (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).
+Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments to which methods are applied. 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:
 

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

@@ -96,7 +96,7 @@ As of [#4971](https://github.com/scala/scala/pull/4971), we treat Single Abstrac
     (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).
+Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments to which methods are applied. 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:
 

_posts/2016-09-06-release-notes-2.12.0-RC1.md

@@ -153,7 +153,7 @@ As of [#4971](https://github.com/scala/scala/pull/4971), we treat Single Abstrac
     (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).
+Type inference in this scenario only works when we can narrow the overloads down to one before type checking the arguments to which methods are applied. 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: