Fixed typos (#513)

Author: vallentin

posts/2015-01-09-Rust-1.0-alpha.md

@@ -84,7 +84,7 @@ have been approved, and are largely summarized [in the Rust Guidelines](http://a
 
 * **Rust by Example:** The lovely http://rustbyexample.com/ introduction to Rust is now part of the official documentation. *Initiated by Jorge Aparicio*.
 
-* **Additional API documentation:** A lot of work has gone into improving API documentation, both by expanding the overview text and adding examples throughout. *Credit goes to the the entire community, who worked tirelessly to improve these docs*.
+* **Additional API documentation:** A lot of work has gone into improving API documentation, both by expanding the overview text and adding examples throughout. *Credit goes to the entire community, who worked tirelessly to improve these docs*.
 
 ### What remains to be done?
 

posts/2016-08-10-Shape-of-errors-to-come.md

@@ -42,15 +42,15 @@ of what is going on.
 The key insight is putting your source code front and center - everything you see in the output
 builds on _your_ code.
 By using the code you wrote as the context, we give you an easy way to know at a glance
-where the issue is occuring.
+where the issue is occurring.
 
 ![Picture of new constant eval error][new_errors2]
 
 *Constant evaluation errors*
 
 Next, once we know the location, we need to explain what is going wrong. We do this by labeling
 points of interest in the code that helped explain
-the error.  The most obvious place to begin labeling is where the error has occured. It's the
+the error.  The most obvious place to begin labeling is where the error has occurred. It's the
 "what" of the error.
 
 In this example, you can see how we use these primary labels. With them, your eyes can see both the
@@ -64,7 +64,7 @@ to quickly spot the error and understand what's going wrong.
 *Mismatch with trait requirement error*
 
 The source of the error is not the only point of interest.  There are often other points of interest
-that help describe "why" an error is occuring. By reading these secondary labels,
+that help describe "why" an error is occurring. By reading these secondary labels,
 you can understand better what is going wrong. These labels are shown in the same order they appear
 in your code, again, to ensure you're always able to, at a glance, understand where you are.
 

posts/2017-03-02-lang-ergonomics.md

@@ -109,7 +109,7 @@ One route for strongly limiting context-dependence is employing *conventions*,
 in which the compiler is simply assuming a default unless told otherwise. Often
 such conventions are universal and well-known, meaning that you don't need to
 know anything about the rest of the code to know what they are. A good example
-of this technique in Rust is the the fact that `mod foo;` looks for `foo.rs` (or
+of this technique in Rust is the fact that `mod foo;` looks for `foo.rs` (or
 `foo/mod.rs`) by default.
 
 One final point. "Implicitness" is often relative to where the language is

posts/2018-06-21-Rust-1.27.md

@@ -78,7 +78,7 @@ While stable Rust has always been able to take advantage of
 autovectorization, sometimes, the compiler just isn't smart enough to realize
 that we can do something like this. Additionally, not every CPU has these
 features, and so LLVM may not use them so your program can be used on a wide
-variety of hardware. So, in Rust 1.27, the addtion of [the `std::arch`
+variety of hardware. So, in Rust 1.27, the addition of [the `std::arch`
 module] allows us to use these kinds of instructions *directly*, which
 means we don't need to rely on a smart compiler. Additionally, it includes
 some features that allow us to choose a particular implementation based
@@ -102,7 +102,7 @@ fn foo() {
 ```
 
 Here, we use `cfg` flags to choose the correct version based on the machine
-we're targetting; on `x86` we use that version, and on `x86_64` we use
+we're targeting; on `x86` we use that version, and on `x86_64` we use
 its version. We can also choose at runtime:
 
 ```rust

posts/2018-10-19-Update-on-crates.io-incident.md

@@ -104,7 +104,7 @@ policy is:
 > stable.
 
 > A more case-by-case policy would be very hard to get right, and would almost
-> certainly result in bad mistakes and and regular controversies.
+> certainly result in bad mistakes and regular controversies.
 
 > Instead, we are going to stick to a first-come, first-served system. If someone
 > wants to take over a package, and the previous owner agrees, the existing

posts/2019-05-14-Rust-1.34.2.md

@@ -36,7 +36,7 @@ of Rust 1.34.0. This point release **destabilizes** it, preventing any code on
 the stable and beta channels to implement or use it, awaiting future plans that
 will be discussed in [issue #60784][60784].
 
-An in-depth explaination of this issue was posted in yesterday's [security
+An in-depth explanation of this issue was posted in yesterday's [security
 advisory][ml]. The assigned CVE for the vulnerability is [CVE-2019-12083][cve].
 
 [ml]: https://groups.google.com/d/msg/rustlang-security-announcements/aZabeCMUv70/-2Y6-SL6AQAJ

posts/2019-05-23-Rust-1.35.0.md

@@ -170,7 +170,7 @@ fn main() {
 
 In 1.35.0, a number of APIs have become stable.
 
-In addition, some implementations were added and other changes occured as well.
+In addition, some implementations were added and other changes occurred as well.
 See the [detailed release notes][notes] for more details.
 
 #### Copy the sign of a floating point number onto another

posts/2019-09-30-Security-advisory-for-cargo.md

@@ -25,7 +25,7 @@ Rust 1.31.0 [introduced a new feature of Cargo][1] where one of the optional key
 serde1 = { version = "1.0", features = ['derive'], package = "serde" }
 ```
 
-It's the addition of the `package` key that causes Cargo to compile the crate differently. This feature was [first implemented][3] in Rust 1.26.0, but it was unstable at the time. For Rust 1.25.0 and prior, however, Cargo would ignore the `package` key and and interpret the dependency line as if it were:
+It's the addition of the `package` key that causes Cargo to compile the crate differently. This feature was [first implemented][3] in Rust 1.26.0, but it was unstable at the time. For Rust 1.25.0 and prior, however, Cargo would ignore the `package` key and interpret the dependency line as if it were:
 
 ```toml
 serde1 = { version = "1.0", features = ['derive'] }