Fix typos in SIPs

_sips/sips/2011-10-12-implicit-classes.md

@@ -30,7 +30,7 @@ argument in its first parameter list. It may also include an
 additional implicit parameter list. An implicit class must be defined
 in a scope where method definitions are allowed (not at the top
 level).  An implicit class is desugared into a class and implicit
-method pairing, where the implciit method mimics the constructor of
+method pairing, where the implicit method mimics the constructor of
 the class.
 
 The generated implicit method will have the same name as the implicit

_sips/sips/2012-01-30-value-classes.md

@@ -136,7 +136,7 @@ is expanded to the following method in the companion object of class `C`:
 
     def extension$m($this: C, params): R = body2
 
-Here `body2` is the same as `body` with each occurence of `this` or `C.this`
+Here `body2` is the same as `body` with each occurrence of `this` or `C.this`
 replaced by `$this`. The original method `m` in `C` will be changed to
 
     def m(params): R = C.extension$m(this, params)
@@ -214,7 +214,7 @@ will be eliminated again in step 4). The newly generated type is assumed to have
 no members and to be completely outside the normal Scala class hierarchy. That
 is, it is a subtype of no other type and is a supertype only of `scala.Nothing`.
 
-We now replace every occurence of the type `C` in a symbol's type or in a tree's
+We now replace every occurrence of the type `C` in a symbol's type or in a tree's
 type annotation by `C$unboxed`. There are however the following two exceptions
 to this rule:
 
@@ -223,7 +223,7 @@ to this rule:
 
         e.isInstanceOf[C]
 
-2. All occurences of methods in class `C` are left unaffected.
+2. All occurrences of methods in class `C` are left unaffected.
 
 We then re-typecheck the program, performing the following adaptations if types
 do not match up.

_sips/sips/2013-05-31-improved-lazy-val-initialization.md

@@ -679,7 +679,7 @@ For those wishing to reproduce the results, the benchmarking suite takes 90 minu
 The final result of those benchmarks is that amount proposed versions, the two that worth considering are (V4-general) and (V6).
 They both perform better than the current implementation in all the contended case.
 Specifically, in the contended case, V6 is 2 times fater than V1, while V4-general is 4 times faster.
-Unfortunately V4-general is 30% slower in the uncontended case than current implemetation(V1), while V6 is in the same ballpark, being up to 5% slower or faster depending on the setup of the benchmark.
+Unfortunately V4-general is 30% slower in the uncontended case than current implementation(V1), while V6 is in the same ballpark, being up to 5% slower or faster depending on the setup of the benchmark.
 
 Based on this, we propose V6 to be used as default in future versions of Scala.
 

_sips/sips/2014-06-27-42.type.md

@@ -490,7 +490,7 @@ applications which work with large datasets.
   derivation.
 
   Implicit resolution is Scala's mechanism for inferring values from types and in current Scala
-  shapeless provides a macro-based materialier for instances of its `Witness` type class. This SIP
+  shapeless provides a macro-based materializer for instances of its `Witness` type class. This SIP
   adds a directly compiler supported type class as a replacement,
 
   ```

_sips/sips/2016-01-11-static-members.md

@@ -106,7 +106,7 @@ The following rules ensure that methods can be correctly compiled into static me
 
 1. Only objects can have members annotated with `@static`
 
-2. The fields annotated with `@static` should preceed any non-`@static` fields. This ensures that we do not introduce surprises for users in initialization order of this class.
+2. The fields annotated with `@static` should precede any non-`@static` fields. This ensures that we do not introduce surprises for users in initialization order of this class.
 
 3. The right hand side of a method or field annotated with `@static` can only refer to top-level classes, members of globally accessible objects and `@static` members. In particular, for non-static objects `this` is not accesible. `super` is never accessible.
 
@@ -205,12 +205,12 @@ Let's consider possible options:
  - if the field `c` is emitted as `static` on the bytecode level, it will be initialized before the `c` in superclass is initialized, reordering side-effects in initializers;
  - if the field `c` is _not_ emitted as `static` but the field `d` is, then the order of initialization would also be affected, reordering side-effects.
 
-Based on the previous study done in preparation for this SIP, the authors believe that the only reasonable way to maintain current sematics would be to say that such alternative would require these rules:
+Based on the previous study done in preparation for this SIP, the authors believe that the only reasonable way to maintain current semantics would be to say that such alternative would require these rules:
 
  - only the fields which were not declared by parents of the object can be emitted as static;
  - only fields that are lexically defined before any non-static field or statement in the body can be emitted as static.
 
-Authors believe that the alternative would require the same effort to implement, but will be less intuitive to users and harder to control as, for example, reodering fields in object might not be binary compatible.
+Authors believe that the alternative would require the same effort to implement, but will be less intuitive to users and harder to control as, for example, reordering fields in object might not be binary compatible.
 
 ## See Also ##
  * [SI-4581](https://issues.scala-lang.org/browse/SI-4581) is a request for a `@static` annotation

_sips/sips/2016-07-25-unsigned-integers.md

@@ -468,7 +468,7 @@ arithmetic expressions for all number types (both primitive signed ones and
 user-defined unsigned ones.)
 
 For each type we've generated 4 benchmarks that use `+, -, *` ops (fastops)
-and 4 benchmarks that use `+, -, *, /, %` (allops). Each of the 4 benchmarks uses exatly
+and 4 benchmarks that use `+, -, *, /, %` (allops). Each of the 4 benchmarks uses exactly
 the same arithmetic expressions for all types. Benchmarks on bytes and shorts wrap back
 to corresponding type after each operation.
 

_sips/sips/2016-09-09-inline-meta.md

@@ -408,7 +408,7 @@ do these desugarings, and scala.meta shields us from this fact.
 We can use the WYSIWYG pattern `q"$_($prefix)"` in order to unwrap the original prefix of the call.
 
 Moreover, we don't have to worry about the compiler internally mangling non-alphanumeric names.
-Again, even if the underying macro engine internally does name mangling, scala.meta abstracts away such implementation details.
+Again, even if the underlying macro engine internally does name mangling, scala.meta abstracts away such implementation details.
 
 Finally, we are able to improve on scala.reflect thanks to more precise quasiquotes.
 If in the current macro system, we used `q"($name: $_) => ..."` to match the `fn` argument,

_sips/sips/2017-01-13-binary-compatibility.md

@@ -161,7 +161,7 @@ class FeaturesInBodies {
 
 ## Features that will fail compilation with `@stableABI`
 The features listed below have complex encodings that may change in future versions. We prefer not to compromise on them.
-Most of those features can be simulated in a binary compatible way by writing a verbose re-implemtation
+Most of those features can be simulated in a binary compatible way by writing a verbose re-implementation
 which won't rely on desugaring performed inside compiler.
 Note that while those features are prohibited in the public API, they can be safely used inside bodies of the methods.
 
@@ -237,7 +237,7 @@ across major versions, while MiMa checks that previously published artifacts ind
 so introduction of new members won't be prohibited. This is a use-case for MiMa.
 
 MiMa does not indicate how hard, if possible, would it be to maintain compatibility of a class across future versions of Scala.
-Multiple features of Scala, most notably lazy vals and traits, have been compiled diffently by different Scala versions
+Multiple features of Scala, most notably lazy vals and traits, have been compiled differently by different Scala versions
 making porting existing compiled bytecode across versions very hard.
 MiMa will complain retroactively that the new version is incompatible with the old one.
 `@stableABI` will instead indicate at compile time that the old version used features whose encoding is prone to change.

_sips/sips/2017-09-20-opaque-types.md

@@ -498,7 +498,7 @@ package object fixed {
 
 This is an interesting example which is intended to show that opaque
 types (unlike type aliases) have an independent existence, even within
-the companion. This means that unlike type alises, `Fix[F]` should not
+the companion. This means that unlike type aliases, `Fix[F]` should not
 result in an infinite expansion in the above code.
 
 The `Fix` type is useful to implementing recursion schemes, or just
@@ -663,7 +663,7 @@ package object groups {
 The example demonstrates using an abstract class (`Wrapper`) to share
 code between opaque type companion objects. Like the tagging example,
 we can use two methods (`wraps` and `unwraps`) to wrap and unwrap `A`
-types, even if neseted in an arbitrary context (`G[_]`). These methods
+types, even if nested in an arbitrary context (`G[_]`). These methods
 cannot be implemented in `Wrapper` because each opaque type companion
 contains the only scope where its particular methods can be
 implemented.
@@ -747,7 +747,7 @@ There are several key ideas in the current, work-in-progress implementation:
  * To meet the type equivalence relationship for opaque types, we synthesize two implicit conversions
    inside the opaque type companion, if they do not already exist. If `opaque type t = T`, then
    two implicit conversions are synthesized, one from `t` to `T` is synthesized and another for the
-   other way around. The body of these methods will use `t.asInstanceOf[T]` and viceversa **.
+   other way around. The body of these methods will use `t.asInstanceOf[T]` and vice versa **.
 
  * Phases after typer always dealias opaque types. This way, erasure and codegen can unwrap opaque
    types out of the box and, at the bytecode level, their underlying representation is used instead.