` is one of:
+
+* `ne` - native endianness
+* `le` - little endian
+* `be` - big endian
+
+See the [detailed release notes][notes] for more details.
+
+### Cargo features
+
+Cargo gained [`cargo c` as an alias for `cargo
+check`](https://github.com/rust-lang/cargo/pull/6218/), and now [allows
+usernames in registry URLs](https://github.com/rust-lang/cargo/pull/6242/).
+
+See the [detailed release notes][notes] for more.
+
+## Contributors to 1.32.0
+
+Many people came together to create Rust 1.32.0. We couldn't have done it
+without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.32.0)
diff --git a/content/Rust-1.33.0.md b/content/Rust-1.33.0.md
new file mode 100644
index 000000000..a462945fd
--- /dev/null
+++ b/content/Rust-1.33.0.md
@@ -0,0 +1,179 @@
++++
+path = "2019/02/28/Rust-1.33.0"
+title = "Announcing Rust 1.33.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/02/28/Rust-1.33.0.html",
+ "releases/1.33.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.33.0. Rust is a
+programming language that is empowering everyone to build reliable and
+efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust
+1.33.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the
+appropriate page on our website, and check out the [detailed release notes for
+1.33.0][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1330-2019-02-28
+
+## What's in 1.33.0 stable
+
+The two largest features in this release are significant improvements to
+`const fn`s, and the stabilization of a new concept: "pinning."
+
+### `const fn` improvements
+
+With `const fn`, you can [now do way more
+things!](https://github.com/rust-lang/rust/pull/57175/) Specifically:
+
+* irrefutable destructuring patterns (e.g. `const fn foo((x, y): (u8, u8)) { ... }`)
+* `let` bindings (e.g. `let x = 1;`)
+* mutable `let` bindings (e.g. `let mut x = 1;`)
+* assignment (e.g. `x = y`) and assignment operator (e.g. `x += y`)
+ expressions, even where the assignment target is a projection (e.g. a struct
+ field or index operation like `x[3] = 42`)
+* expression statements (e.g. `3;`)
+
+You're also [able to call `const unsafe fn`s inside a `const
+fn`](https://github.com/rust-lang/rust/pull/57067/), like this:
+
+```rust
+const unsafe fn foo() -> i32 { 5 }
+const fn bar() -> i32 {
+ unsafe { foo() }
+}
+```
+
+With these additions, many more functions in the standard library are able to
+be marked as `const`. We'll enumerate those in the library section below.
+
+### Pinning
+
+This release introduces a new concept for Rust programs, implemented as two
+types: the [`std::pin::Pin`
+type](https://doc.rust-lang.org/std/pin/struct.Pin.html), and the [`Unpin`
+marker trait](https://doc.rust-lang.org/std/marker/trait.Unpin.html). The core
+idea is elaborated on in [the docs for
+`std::pin`](https://doc.rust-lang.org/std/pin/index.html):
+
+> It is sometimes useful to have objects that are guaranteed to not move, in
+> the sense that their placement in memory does not change, and can thus be
+> relied upon. A prime example of such a scenario would be building
+> self-referential structs, since moving an object with pointers to itself will
+> invalidate them, which could cause undefined behavior.
+>
+> A `Pin
` ensures that the pointee of any pointer type `P` has a stable location
+> in memory, meaning it cannot be moved elsewhere and its memory cannot be
+> deallocated until it gets dropped. We say that the pointee is "pinned".
+
+This feature will largely be used by library authors, and so we won't talk a
+lot more about the details here. Consult the docs if you're interested in
+digging into the details. However, the stabilization of this API is important
+to Rust users generally because it is a significant step forward towards a
+highly anticipated Rust feature: `async`/`await`. We're not quite there yet,
+but this stabilization brings us one step closer. You can track all of the
+necessary features at [areweasyncyet.rs](https://areweasyncyet.rs/).
+
+### Import as `_`
+
+[You can now import an item as
+`_`](https://github.com/rust-lang/rust/pull/56303/). This allows you to
+import a trait's impls, and not have the name in the namespace. e.g.
+
+```rust
+use std::io::Read as _;
+
+// Allowed as there is only one `Read` in the module.
+pub trait Read {}
+```
+
+See the [detailed release notes][notes] for more details.
+
+### Library stabilizations
+
+Here's all of the stuff that's been made `const`:
+
+- [The methods `overflowing_{add, sub, mul, shl, shr}` are now `const`
+ functions for all numeric types.][57566]
+- [The methods `rotate_left`, `rotate_right`, and `wrapping_{add, sub, mul, shl, shr}`
+ are now `const` functions for all numeric types.][57105]
+- [The methods `is_positive` and `is_negative` are now `const` functions for
+ all signed numeric types.][57105]
+- [The `get` method for all `NonZero` types is now `const`.][57167]
+- [The methods `count_ones`, `count_zeros`, `leading_zeros`, `trailing_zeros`,
+ `swap_bytes`, `from_be`, `from_le`, `to_be`, `to_le` are now `const` for all
+ numeric types.][57234]
+- [`Ipv4Addr::new` is now a `const` function][57234]
+
+[57566]: https://github.com/rust-lang/rust/pull/57566
+[57105]: https://github.com/rust-lang/rust/pull/57105
+[57105]: https://github.com/rust-lang/rust/pull/57105
+[57167]: https://github.com/rust-lang/rust/pull/57167
+[57234]: https://github.com/rust-lang/rust/pull/57234
+[57234]: https://github.com/rust-lang/rust/pull/57234
+
+Additionally, these APIs have become stable:
+
+- [`unix::FileExt::read_exact_at`] and [`unix::FileExt::write_all_at`]
+- [`Option::transpose`] and [`Result::transpose`]
+- [`convert::identity`]
+- [`pin::Pin`] and [`marker::Unpin`] (mentioned above)
+- [`marker::PhantomPinned`]
+- [`Vec::resize_with`] and [`VecDeque::resize_with`]
+- [`Duration::as_millis`], [`Duration::as_micros`], and [`Duration::as_nanos`]
+
+[`unix::FileExt::read_exact_at`]: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#method.read_exact_at
+[`unix::FileExt::write_all_at`]: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#method.write_all_at
+[`Option::transpose`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.transpose
+[`Result::transpose`]: https://doc.rust-lang.org/std/result/enum.Result.html#method.transpose
+[`convert::identity`]: https://doc.rust-lang.org/std/convert/fn.identity.html
+[`pin::Pin`]: https://doc.rust-lang.org/std/pin/struct.Pin.html
+[`marker::Unpin`]: https://doc.rust-lang.org/stable/std/marker/trait.Unpin.html
+[`marker::PhantomPinned`]: https://doc.rust-lang.org/nightly/std/marker/struct.PhantomPinned.html
+[`Vec::resize_with`]: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.resize_with
+[`VecDeque::resize_with`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.resize_with
+[`Duration::as_millis`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_millis
+[`Duration::as_micros`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_micros
+[`Duration::as_nanos`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_nanos
+
+See the [detailed release notes][notes] for more details.
+
+### Cargo features
+
+[Cargo should now rebuild a crate if a file was modified during the initial
+build.](https://github.com/rust-lang/cargo/pull/6484/)
+
+See the [detailed release notes][notes] for more.
+
+### Crates.io
+
+[As previously announced][urlo-ann], coinciding with this release, crates.io
+will require that you have a verified email address to publish. Starting at
+2019-03-01 00:00 UTC, if you don't have a verified email address and run `cargo
+publish`, you'll get an error.
+
+This ensures we can comply with DMCA procedures. If you haven't heeded the
+warnings cargo printed during the last release cycle, head on over to
+[crates.io/me][me] to set and verify your email address. This email address
+will never be displayed publicly and will only be used for crates.io operations.
+
+[urlo-ann]: https://users.rust-lang.org/t/a-verified-email-address-will-be-required-to-publish-to-crates-io-starting-on-2019-02-28/22425
+[me]: https://crates.io/me
+
+## Contributors to 1.33.0
+
+Many people came together to create Rust 1.33.0. We couldn't have done it
+without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.33.0)
diff --git a/content/Rust-1.34.0.md b/content/Rust-1.34.0.md
new file mode 100644
index 000000000..d5e1c06be
--- /dev/null
+++ b/content/Rust-1.34.0.md
@@ -0,0 +1,225 @@
++++
+path = "2019/04/11/Rust-1.34.0"
+title = "Announcing Rust 1.34.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/04/11/Rust-1.34.0.html",
+ "releases/1.34.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.34.0. Rust is a
+programming language that is empowering everyone to build reliable and
+efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust
+1.34.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate
+page on our website.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1340-2019-04-11
+
+## What's in 1.34.0 stable
+
+The largest feature in this release is the introduction of *alternative* `cargo` registries.
+The release also includes support for `?` in documentation tests,
+some improvements for `#[attribute(..)]`s, as well as the stabilization of `TryFrom`.
+Read on for a few highlights, or see the [detailed release notes][notes] for additional information.
+
+### Alternative `cargo` registries
+
+[crates.io]: http://crates.io/
+[registry-docs]: https://doc.rust-lang.org/nightly/cargo/reference/registries.html#running-a-registry
+
+Since before 1.0, Rust has had a public crate registry, [crates.io].
+People publish crates with `cargo publish` and it's easy to include these crates
+in the `[dependencies]` section of your `Cargo.toml`.
+
+However, not everyone _wants_ to publish their crates to crates.io.
+People maintaining proprietary/closed-source code cannot use crates.io,
+and instead are forced to use `git` or `path` dependencies.
+This is usually fine for small projects, but if you have a lot of closed-source crates
+within a large organization, you lose the benefit of the versioning support that crates.io has.
+
+With this release, Cargo gains support for alternate registries.
+These registries coexist with crates.io, so you can write software that depends
+on crates from both crates.io and your custom registry.
+Crates on crates.io cannot however depend on external registries.
+
+To use an alternate registry, you must add these lines to your `.cargo/config`.
+This file can be in your home directory (`~/.cargo/config`) or relative to the package directory.
+
+```toml
+[registries]
+my-registry = { index = "https://my-intranet:8080/git/index" }
+```
+
+Depending on a crate from an alternate registry is easy.
+When specifying dependencies in your `Cargo.toml`, use the `registry` key to
+let Cargo know that you wish to fetch the crate from the alternate registry:
+
+```toml
+[dependencies]
+other-crate = { version = "1.0", registry = "my-registry" }
+```
+
+As a crate author, if you wish to publish your crate to an alternate registry,
+you first need to save the authentication token into `~/.cargo/credentials` with the `cargo login` command:
+
+```sh
+cargo login --registry=my-registry
+```
+
+You can then use the `--registry` flag to indicate which registry to use when publishing:
+
+```sh
+cargo publish --registry=my-registry
+```
+
+There is [documentation][registry-docs] on how to run your own registry.
+
+### `?` in documentation tests
+
+[RFC 1937]: https://rust-lang.github.io/rfcs/1937-ques-in-main.html
+[many releases ago]: https://blog.rust-lang.org/2018/05/10/Rust-1.26.html#main-can-return-a-result
+
+[RFC 1937] proposed adding support for using the `?` operator in `fn main()`,
+`#[test]` functions, and doctests, allowing them to return `Option` or `Result`,
+with error values causing a nonzero exit code in the case of `fn main()`,
+and a test failure in the case of the tests.
+
+Support in `fn main()` and `#[test]` was implemented [many releases ago].
+However, the support within documentation tests was limited to doctests that have an explicit `fn main()`.
+
+In this release, full support for `?` in doctests has been added.
+Now, you can write this in your documentation tests:
+
+````rust
+/// ```rust
+/// use std::io;
+/// let mut input = String::new();
+/// io::stdin().read_line(&mut input)?;
+/// # Ok::<(), io::Error>(())
+/// ```
+fn my_func() {}
+````
+
+You still have to specify the error type being used at the bottom of the documentation test.
+
+### Custom attributes accept arbitrary token streams
+
+[Procedural macros]: https://blog.rust-lang.org/2018/12/21/Procedural-Macros-in-Rust-2018.html
+[arbitrary-tts]: https://github.com/rust-lang/rust/pull/57367
+
+[Procedural macros] in Rust can define custom attributes that they consume.
+Until now, such attributes were restricted to being trees of paths and literals
+according to a specific syntax, like:
+
+```rust
+#[foo(bar)]
+#[foo = "bar"]
+#[foo = 0]
+#[foo(bar = true)]
+#[foo(bar, baz(quux, foo = "bar"))]
+```
+
+Unlike procedural macros, these helper attributes could not accept arbitrary token streams in delimiters,
+so you could not write `#[range(0..10)]` or `#[bound(T: MyTrait)]`.
+Procedural macro crates would instead use strings for specifying syntaxes like this, e.g. `#[range("0..10")]`
+
+With this Rust release, custom attributes `#[attr($tokens)]` [now accept][arbitrary-tts]
+arbitrary token streams in `$tokens`, bringing them on par with macros.
+If you're the author of a procedural macro crate, please check if your custom attributes
+have unnecessary strings in their syntax and if they can be better expressed with token streams.
+
+### `TryFrom` and `TryInto`
+
+[`from_be_bytes`]: https://doc.rust-lang.org/std/primitive.u32.html#method.from_be_bytes
+[never_type]: https://github.com/rust-lang/rust/issues/35121
+[`TryFrom`]: https://doc.rust-lang.org/std/convert/trait.TryFrom.html
+[`TryInto`]: https://doc.rust-lang.org/std/convert/trait.TryInto.html
+[`Infallible`]: https://doc.rust-lang.org/std/convert/enum.Infallible.html
+
+The [`TryFrom`] and [`TryInto`] traits were stabilized to allow fallible type conversions.
+
+For example, the [`from_be_bytes`] and related methods on integer types take arrays,
+but data is often read in via slices. Converting between slices and arrays is tedious to do manually.
+With the new traits, it can be done inline with `.try_into()`.
+
+```rust
+let num = u32::from_be_bytes(slice.try_into()?);
+```
+
+For conversions that cannot fail, such as `u8` to `u32`, the [`Infallible`] type was added.
+This also permits a blanket implementation of `TryFrom` for all existing `From` implementations.
+In the future, we hope to turn `Infallible` into an alias for [the `!` (never) type][never_type].
+
+### `fn before_exec` deprecated in favor of `unsafe fn pre_exec`
+
+[`CommandExt::before_exec`]: https://doc.rust-lang.org/std/os/unix/process/trait.CommandExt.html#tymethod.before_exec
+[`CommandExt::pre_exec`]: https://doc.rust-lang.org/std/os/unix/process/trait.CommandExt.html#tymethod.pre_exec
+[ub-possible]: https://github.com/rust-lang/rust/issues/39575#issuecomment-437658766
+[non-dup]: https://github.com/rust-lang/rust/issues/39575#issuecomment-439645949
+
+On Unix-like systems, the function [`CommandExt::before_exec`] allows you to
+schedule a closure to be run before `exec` is invoked.
+
+The closure provided will be run in the context of the child process after a fork.
+This means that resources, such as file descriptors and memory-mapped regions, may get duplicated.
+In other words, you can now copy a value of a non-`Copy` type into a different process
+while retaining the original in the parent. This makes [it possible][ub-possible] to cause
+undefined behavior and break [libraries assuming non-duplication][non-dup].
+
+The function `before_exec` should therefore have been marked as `unsafe`.
+In this release of Rust, we have deprecated `fn before_exec` in favor of the `unsafe fn pre_exec`.
+When calling [`CommandExt::pre_exec`], it is your responsibility to make sure that the closure
+does not violate library invariants by making invalid use of these duplicates.
+If you provide a library that is in a similar situation as `before_exec`,
+consider deprecating and providing an `unsafe` alternative as well.
+
+### Library stabilizations
+
+[`AtomicU8`]: https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU8.html
+[`NonZeroU8`]: https://doc.rust-lang.org/std/num/struct.NonZeroU8.html
+[`NonZeroI8`]: https://doc.rust-lang.org/std/num/struct.NonZeroI8.html
+[`iter::from_fn`]: https://doc.rust-lang.org/std/iter/fn.from_fn.html
+[`iter::successors`]: https://doc.rust-lang.org/std/iter/fn.successors.html
+[prev-1.28]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1280-2018-08-02
+
+In 1.34.0, the set of stable atomic integer types was expanded,
+with signed and unsigned variants from 8 ([`AtomicU8`]) to 64 bits now available.
+
+[Previously][prev-1.28], non-zero unsigned integer types, e.g. [`NonZeroU8`], were stabilized.
+This gave `Option` the same size as `u8`.
+With this Rust release, signed versions, e.g. [`NonZeroI8`], have been stabilized.
+
+The functions [`iter::from_fn`] and [`iter::successors`] have been stabilized.
+The former allows you to construct an iterator from `FnMut() -> Option`.
+To pop elements from a vector iteratively, you can now write `from_fn(|| vec.pop())`.
+Meanwhile, the latter creates a new iterator where each successive item
+is computed based on the preceding one.
+
+Additionally, these APIs have become stable:
+
+- [Any::type_id](https://doc.rust-lang.org/std/any/trait.Any.html#tymethod.type_id)
+- [Error::type_id](https://doc.rust-lang.org/std/error/trait.Error.html#method.type_id)
+- [slice::sort_by_cached_key](https://doc.rust-lang.org/std/primitive.slice.html#method.sort_by_cached_key)
+- [str::escape_debug](https://doc.rust-lang.org/std/primitive.str.html#method.escape_debug)
+- [str::escape_default](https://doc.rust-lang.org/std/primitive.str.html#method.escape_default)
+- [str::escape_unicode](https://doc.rust-lang.org/std/primitive.str.html#method.escape_unicode)
+- [str::split_ascii_whitespace](https://doc.rust-lang.org/std/primitive.str.html#method.split_ascii_whitespace)
+- [Instant::checked_add](https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_add)
+- [Instant::checked_sub](https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_sub)
+- [SystemTime::checked_add](https://doc.rust-lang.org/std/time/struct.SystemTime.html#method.checked_add)
+- [SystemTime::checked_sub](https://doc.rust-lang.org/std/time/struct.SystemTime.html#method.checked_sub)
+
+See the [detailed release notes][notes] for more details.
diff --git a/content/Rust-1.34.1.md b/content/Rust-1.34.1.md
new file mode 100644
index 000000000..23a9554be
--- /dev/null
+++ b/content/Rust-1.34.1.md
@@ -0,0 +1,78 @@
++++
+path = "2019/04/25/Rust-1.34.1"
+title = "Announcing Rust 1.34.1"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/04/25/Rust-1.34.1.html",
+ "releases/1.34.1",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.34.1, and a new version of rustup, 1.18.1.
+Rust is a programming language that is empowering everyone to build reliable and efficient software.
+
+If you have a previous version of Rust installed via rustup,
+getting Rust 1.34.1 and rustup 1.18.1 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate page on our website.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1341-2019-04-25
+
+## What's in 1.34.1 stable
+
+[Clippy]: https://github.com/rust-lang/rust-clippy
+[panic]: https://github.com/rust-lang/rust-clippy/pull/3805
+
+This patch release fixes two false positives and [a panic when checking macros][panic] in [Clippy].
+Clippy is a tool which provides a collection of lints to catch common mistakes and improve your Rust code.
+
+### False positive in `clippy::redundant_closure`
+
+A false positive in the `redundant_closure` lint was [fixed](https://github.com/rust-lang/rust-clippy/pull/3821).
+The lint did not take into account [differences in the number of borrows](https://github.com/rust-lang/rust-clippy/issues/3802).
+
+In the following snippet, the method `required` expects `dep: &D` but the actual type of `dep` is `&&D`:
+
+```rust
+dependencies.iter().filter(|dep| dep.required());
+```
+
+Clippy erronously suggested `.filter(Dependency::required)`,
+which is rejected by the compiler due to the difference in borrows.
+
+### False positive in `clippy::missing_const_for_fn`
+
+Another false positive in the `missing_const_for_fn` lint was [fixed](https://github.com/rust-lang/rust-clippy/pull/3844).
+This lint did not take into account that functions inside `trait` implementations cannot be `const fn`s.
+For example, when given the following snippet, the lint would trigger:
+
+```rust
+#[derive(PartialEq, Eq)] // warning: this could be a const_fn
+struct Point(isize, isize);
+
+impl std::ops::Add for Point {
+ type Output = Self;
+
+ fn add(self, other: Self) -> Self { // warning: this could be a const_fn
+ Point(self.0 + other.0, self.1 + other.1)
+ }
+}
+```
+
+## What's new in rustup 1.18.1
+
+[a regression]: https://github.com/rust-lang/rustup.rs/issues/1794
+[full release notes]: https://github.com/rust-lang/rustup.rs/blob/master/CHANGELOG.md#1181---2019-04-25
+
+A recent rustup release, 1.18.0, introduced [a regression] that prevented installing Rust through the shell script on older platforms.
+A patch was released that fixes the issue, avoiding to force TLS v1.2 on the platforms that don't support it.
+
+You can check out other rustup changes in its [full release notes].
diff --git a/content/Rust-1.34.2.md b/content/Rust-1.34.2.md
new file mode 100644
index 000000000..35a0b6a52
--- /dev/null
+++ b/content/Rust-1.34.2.md
@@ -0,0 +1,53 @@
++++
+path = "2019/05/14/Rust-1.34.2"
+title = "Announcing Rust 1.34.2"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/05/14/Rust-1.34.2.html",
+ "releases/1.34.2",
+]
+
+[extra]
+release = true
++++
+
+The Rust team has published a new point release of Rust, 1.34.2. Rust is a
+programming language that is empowering everyone to build reliable and
+efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust
+1.34.2 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the
+appropriate page on our website.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1342-2019-05-14
+
+## What's in 1.34.2 stable
+
+Sean McArthur reported a [security vulnerability][ml] affecting the standard
+library that caused the [`Error::downcast`][Error::downcast] family of methods
+to perform unsound casts when a manual implementation of the
+[`Error::type_id`][Error::type_id] method returned the wrong
+[`TypeId`][TypeId], leading to security issues such as out of bounds
+reads/writes/etc.
+
+The [`Error::type_id`][Error::type_id] method was recently stabilized as part
+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 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
+[Error::downcast]: https://doc.rust-lang.org/stable/std/error/trait.Error.html#method.downcast
+[Error::type_id]: https://doc.rust-lang.org/stable/std/error/trait.Error.html#method.type_id
+[TypeId]: https://doc.rust-lang.org/stable/std/any/struct.TypeId.html
+[60784]: https://github.com/rust-lang/rust/issues/60784
+[cve]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12083
diff --git a/content/Rust-1.35.0.md b/content/Rust-1.35.0.md
new file mode 100644
index 000000000..202c42c8c
--- /dev/null
+++ b/content/Rust-1.35.0.md
@@ -0,0 +1,296 @@
++++
+path = "2019/05/23/Rust-1.35.0"
+title = "Announcing Rust 1.35.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/05/23/Rust-1.35.0.html",
+ "releases/1.35.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.35.0. Rust is a
+programming language that is empowering everyone to build reliable and efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust 1.35.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate page on our website,
+and check out the [detailed release notes for 1.35.0][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1350-2019-05-23
+
+## What's in 1.35.0 stable
+
+The highlight of this release is the implementation of the `FnOnce`, `FnMut`,
+and `Fn` closure traits for `Box`, `Box`, and `Box` respectively.
+Additionally, closures may now be coerced to unsafe function pointers.
+The `dbg!` macro introduced in [Rust 1.32.0] can now also be called without arguments.
+Moreover, there were a number of standard library stabilizations.
+Read on for a few highlights, or see the [detailed release notes][notes] for additional information.
+
+### `Fn*` closure traits implemented for `Box`
+
+[fn-pr]: https://github.com/rust-lang/rust/pull/55431
+[`FnBox`]: https://doc.rust-lang.org/1.34.0/std/boxed/trait.FnBox.html
+[unsized locals]: https://doc.rust-lang.org/nightly/unstable-book/language-features/unsized-locals.html
+
+In Rust 1.35.0, the `FnOnce`, `FnMut`, and the `Fn` traits [are now implemented][fn-pr] for `Box`,
+`Box`, and `Box` respectively.
+
+Previously, if you wanted to call the function stored in a boxed closure, you had to use [`FnBox`].
+This was because instances of `Box` and friends did not implement the respective `Fn*` traits.
+This also meant that it was not possible to pass boxed functions to code expecting an implementor of a `Fn` trait,
+and you had to create temporary closures to pass them down.
+
+This was ultimately due to a limitation in the compiler's ability to reason about such implementations,
+which has since been fixed with the introduction of [unsized locals].
+
+With this release, you can now use boxed functions in places that expect items implementing a function trait.
+
+The following code now works:
+
+```rust
+fn foo(x: Box u8>) -> Vec {
+ vec![1, 2, 3, 4].into_iter().map(x).collect()
+}
+```
+
+Furthermore, you can now directly call `Box` objects:
+
+```rust
+fn foo(x: Box) {
+ x()
+}
+```
+
+### Coercing closures to `unsafe fn` pointers
+
+[Rust 1.19.0]: https://blog.rust-lang.org/2017/07/20/Rust-1.19.html
+[`RawWakerVTable`]: https://doc.rust-lang.org/beta/std/task/struct.RawWakerVTable.html
+
+Since [Rust 1.19.0], it has been possible to coerce closures that do not capture from their environment into function pointers.
+For example, you may write:
+
+```rust
+fn twice(x: u8, f: fn(u8) -> u8) -> u8 {
+ f(f(x))
+}
+
+fn main() {
+ assert_eq!(42, twice(0, |x| x + 21));
+}
+```
+
+This has however not extended to `unsafe` function pointers.
+With this release of Rust, you may now do so. For example:
+
+```rust
+/// The safety invariants are those of the `unsafe fn` pointer passed.
+unsafe fn call_unsafe_fn_ptr(f: unsafe fn()) {
+ f()
+}
+
+fn main() {
+ // SAFETY: There are no invariants.
+ // The closure is statically prevented from doing unsafe things.
+ unsafe {
+ call_unsafe_fn_ptr(|| {
+ dbg!();
+ });
+ }
+}
+```
+
+### Calling `dbg!()` with no argument
+
+[Rust 1.32.0]: https://blog.rust-lang.org/2019/01/17/Rust-1.32.0.html#the-dbg-macro
+[the `dbg!` macro]: https://doc.rust-lang.org/std/macro.dbg.html
+
+For the benefit of all the occasional and frequent "print debuggers" out there,
+[Rust 1.32.0] saw the release of [the `dbg!` macro].
+To recap, the macro allows you to quickly inspect the value of some expression with context.
+For example, when running:
+
+```rust
+fn main() {
+ let mut x = 0;
+
+ if dbg!(x == 1) {
+ x += 1;
+ }
+
+ dbg!(x);
+}
+```
+
+...you would see:
+
+```
+[src/main.rs:4] x == 1 = false
+[src/main.rs:8] x = 0
+```
+
+
+As seen in the previous section, where the higher order function `call_unsafe_fn_ptr` is called,
+you may now also call `dbg!` without passing any arguments.
+This is useful when tracing what branches your application takes.
+For example, with:
+
+```rust
+fn main() {
+ let condition = true;
+
+ if condition {
+ dbg!();
+ }
+}
+```
+
+...you would see:
+
+```
+[src/main.rs:5]
+```
+
+### Library stabilizations
+
+[`f32::copysign`]: https://doc.rust-lang.org/std/primitive.f32.html#method.copysign
+[`f64::copysign`]: https://doc.rust-lang.org/std/primitive.f64.html#method.copysign
+[`RefCell::replace_with`]: https://doc.rust-lang.org/std/cell/struct.RefCell.html#method.replace_with
+[`Ref::map_split`]: https://doc.rust-lang.org/std/cell/struct.Ref.html#method.map_split
+[`RefMut::map_split`]: https://doc.rust-lang.org/std/cell/struct.RefMut.html#method.map_split
+[`ptr::hash`]: https://doc.rust-lang.org/std/ptr/fn.hash.html
+[`Range::contains`]: https://doc.rust-lang.org/std/ops/struct.Range.html#method.contains
+[`RangeFrom::contains`]: https://doc.rust-lang.org/std/ops/struct.RangeFrom.html#method.contains
+[`RangeTo::contains`]: https://doc.rust-lang.org/std/ops/struct.RangeTo.html#method.contains
+[`RangeInclusive::contains`]: https://doc.rust-lang.org/std/ops/struct.RangeInclusive.html#method.contains
+[`RangeToInclusive::contains`]: https://doc.rust-lang.org/std/ops/struct.RangeToInclusive.html#method.contains
+[`Option::copied`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.copied
+
+In 1.35.0, a number of APIs have become stable.
+
+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
+
+[`f32`]: https://doc.rust-lang.org/std/primitive.f32.html
+[`f64`]: https://doc.rust-lang.org/std/primitive.f64.html
+
+With this release, new methods `copysign` have been added to the floating point primitive types [`f32`] and [`f64`]:
+
+- [`f32::copysign`]
+- [`f64::copysign`]
+
+As the name suggests, you can use these to copy the sign of one number onto another. For example:
+
+```rust
+fn main() {
+ assert_eq!(3.5_f32.copysign(-0.42), -3.5);
+}
+```
+
+#### Check whether a `Range` `contains` a value
+
+Rust 1.35.0 contains a few freshly minted methods on the `Range` types:
+
+- [`Range::contains`]
+- [`RangeFrom::contains`]
+- [`RangeTo::contains`]
+- [`RangeInclusive::contains`]
+- [`RangeToInclusive::contains`]
+
+With these, you can easily check whether a given value exists in a range. For example, you may write:
+
+```rust
+fn main() {
+ if (0..=10).contains(&5) {
+ println!("Five is included in zero to ten.");
+ }
+}
+```
+
+#### Map and split a borrowed `RefCell` value in two
+
+With Rust 1.35.0, you can now map and split the borrowed value of a `RefCell` into multiple borrows for different components of the borrowed data:
+
+- [`Ref::map_split`]
+- [`RefMut::map_split`]
+
+#### Replace the value of a `RefCell` through a closure
+
+This release introduces a convenience method `replace_with` on `RefCell`:
+
+- [`RefCell::replace_with`]
+
+With it, you can more ergonomically map and replace the current value of the cell and get back the old value as a result.
+
+#### Hash a pointer or reference by address, not value
+
+In this release, we have introduced:
+
+- [`ptr::hash`]
+
+This function takes a raw pointer and hashes it. Using `ptr::hash`,
+you can avoid hashing the pointed-to value of a reference and instead hash the address.
+
+#### Copy the contents of an `Option<&T>`
+
+From the very beginning with Rust 1.0.0,
+the methods `Option::cloned` for `Option<&T>` and `Option<&mut T>` have allowed you to clone the contents in case of `Some(_)`.
+However, cloning can sometimes be an expensive operation and the methods `opt.cloned()` provided no hints to that effect.
+
+With this release of Rust, we introduced:
+
+- [`Option::copied`] for both `Option<&T>` and `Option<&mut T>`
+
+The functionality of `opt.copied()` is the same as for `opt.cloned()`.
+However, calling the method requires that `T: Copy`.
+Using this method, you can make sure that code stops compiling should `T` no longer implements `Copy`.
+
+### Changes in Clippy
+
+[relnotes-clippy]:
+https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-135-beta
+
+[`drop_bounds`]: https://rust-lang.github.io/rust-clippy/master/index.html#drop_bounds
+
+[split_lint]: https://github.com/rust-lang/rust-clippy/pull/4101
+
+In this release of Rust,
+Clippy (a collection of lints to catch common mistakes and improve your Rust code) added a new lint [`drop_bounds`].
+This lint triggers when you add a bound `T: Drop` to a generic function. For example:
+
+```rust
+fn foo(x: T) {}
+```
+
+Having a bound `T: Drop` is almost always a mistake as it excludes types,
+such as `u8`, which have trivial drop-glues.
+Moreover, `T: Drop` does not account for types like `String` not having interesting destructor behavior directly but rather as a result of embedding types,
+such as `Vec`, that do.
+
+In addition to [`drop_bounds`],
+this release of Clippy [split][split_lint] the lint`redundant_closure` into `redundant_closure` and `redundant_closure_for_method_calls`.
+
+See the [detailed release notes for Clippy][relnotes-clippy] for more details.
+
+### Changes in Cargo
+
+[relnotes-cargo]:
+https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-135-2019-05-23
+
+See the [detailed release notes for Cargo][relnotes-cargo] for more details.
+
+## Contributors to 1.35.0
+
+Many people came together to create Rust 1.35.0.
+We couldn't have done it without all of you.
+[Thanks!](https://thanks.rust-lang.org/rust/1.35.0/)
diff --git a/content/Rust-1.36.0.md b/content/Rust-1.36.0.md
new file mode 100644
index 000000000..1fe18c7ae
--- /dev/null
+++ b/content/Rust-1.36.0.md
@@ -0,0 +1,225 @@
++++
+path = "2019/07/04/Rust-1.36.0"
+title = "Announcing Rust 1.36.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/07/04/Rust-1.36.0.html",
+ "releases/1.36.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.36.0.
+Rust is a programming language that is empowering everyone to build reliable and efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust 1.36.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate page on our website,
+and check out the [detailed release notes for 1.36.0][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1360-2019-07-04
+
+## What's in 1.36.0 stable
+
+This release brings many changes, including the stabilization of the [`Future`] trait,
+the [`alloc`][alloc-crate] crate, the [`MaybeUninit`] type, [NLL for Rust 2015][felix-blog],
+a new `HashMap` implementation, and [`--offline`] support in Cargo.
+Read on for a few highlights, or see the [detailed release notes][notes] for additional information.
+
+### The [`Future`] is here!
+
+[`Future`]: https://doc.rust-lang.org/std/future/trait.Future.html
+[pr-future]: https://github.com/rust-lang/rust/pull/59739
+
+In Rust 1.36.0 the long awaited [`Future`] trait has been [stabilized][pr-future]!
+
+With this stabilization, we hope to give important crates, libraries,
+and the ecosystem time to prepare for `async` / `.await`,
+which we'll tell you more about in the future.
+
+### The [`alloc`][alloc-crate] crate is stable
+
+[alloc-crate]: https://doc.rust-lang.org/alloc/index.html
+
+Before 1.36.0, the standard library consisted of the crates `std`, `core`, and `proc_macro`.
+The `core` crate provided core functionality such as `Iterator` and `Copy`
+and could be used in `#![no_std]` environments since it did not impose any requirements.
+Meanwhile, the `std` crate provided types like `Box` and OS functionality
+but required a global allocator and other OS capabilities in return.
+
+Starting with Rust 1.36.0, the parts of `std` that depend on a global allocator, e.g. `Vec`,
+are now available in the `alloc` crate. The `std` crate then re-exports these parts.
+While `#![no_std]` *binaries* using `alloc` still require nightly Rust,
+`#![no_std]` *library* crates can use the `alloc` crate in stable Rust.
+Meanwhile, normal binaries, without `#![no_std]`, can depend on such library crates.
+We hope this will facilitate the development of a `#![no_std]` compatible ecosystem of libraries
+prior to stabilizing support for `#![no_std]` binaries using `alloc`.
+
+If you are the maintainer of a library that only relies on some allocation primitives to function,
+consider making your library `#[no_std]` compatible by using the following at the top of your `lib.rs` file:
+
+```rust
+#![no_std]
+
+extern crate alloc;
+
+use alloc::vec::Vec;
+```
+
+### [`MaybeUninit`] instead of [`mem::uninitialized`]
+
+[`MaybeUninit`]: https://doc.rust-lang.org/std/mem/union.MaybeUninit.html
+[`mem::uninitialized`]: https://doc.rust-lang.org/std/mem/fn.uninitialized.html
+[gankro-blog]: https://gankro.github.io/blah/initialize-me-maybe/
+[pr-60445]: https://github.com/rust-lang/rust/pull/60445
+
+In previous releases of Rust, the [`mem::uninitialized`] function has allowed you to bypass Rust's
+initialization checks by pretending that you've initialized a value at type `T` without doing anything.
+One of the main uses of this function has been to lazily allocate arrays.
+
+However, [`mem::uninitialized`] is an incredibly dangerous operation that essentially
+cannot be used correctly as the Rust compiler assumes that values are properly initialized.
+For example, calling `mem::uninitialized::()` causes *instantaneous __undefined behavior__*
+as, from Rust's point of view, the uninitialized bits are neither `0` (for `false`)
+nor `1` (for `true`) - the only two allowed bit patterns for `bool`.
+
+To remedy this situation, in Rust 1.36.0, the type [`MaybeUninit`] has been [stabilized][pr-60445].
+The Rust compiler will understand that it should not assume that a [`MaybeUninit`] is a properly initialized `T`.
+Therefore, you can do gradual initialization more safely and eventually use `.assume_init()`
+once you are certain that `maybe_t: MaybeUninit` contains an initialized `T`.
+
+As [`MaybeUninit`] is the safer alternative, starting with Rust 1.39,
+the function [`mem::uninitialized`] will be deprecated.
+
+To find out more about uninitialized memory, [`mem::uninitialized`],
+and [`MaybeUninit`], read [Alexis Beingessner's blog post][gankro-blog].
+The standard library also contains extensive documentation about [`MaybeUninit`].
+
+### NLL for Rust 2015
+
+[nll-2018]: https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes
+[soundness]: https://en.wikipedia.org/wiki/Soundness
+[felix-blog]: http://blog.pnkfx.org/blog/2019/06/26/breaking-news-non-lexical-lifetimes-arrives-for-everyone/
+[crater-nll]: https://github.com/rust-lang/rust/issues/60680#issuecomment-495089654
+
+[In the announcement for Rust 1.31.0][nll-2018], we told you about NLL (Non-Lexical Lifetimes),
+an improvement to the language that makes the borrow checker smarter and more user friendly.
+For example, you may now write:
+
+```rust
+fn main() {
+ let mut x = 5;
+ let y = &x;
+ let z = &mut x; // This was not allowed before 1.31.0.
+}
+```
+
+In 1.31.0 NLL was stabilized only for Rust 2018,
+with a promise that we would backport it to Rust 2015 as well.
+With Rust 1.36.0, we are happy to announce that we have done so! NLL is now available for Rust 2015.
+
+With NLL on both editions, we are closer to removing the old borrow checker.
+However, the old borrow checker unfortunately accepted some [unsound][soundness] code it should not have.
+As a result, NLL is currently in a "migration mode" wherein we will emit warnings instead
+of errors if the NLL borrow checker rejects code the old AST borrow checker would accept.
+Please see [this list][crater-nll] of public crates that are affected.
+
+To find out more about NLL, MIR, the story around fixing soundness holes,
+and what you can do about the warnings if you have them, read [Felix Klock's blog post][felix-blog].
+
+### A new [`HashMap`] implementation
+
+[`hashbrown`]: https://crates.io/crates/hashbrown
+[`HashMap`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html
+[pr-hashbrown]: https://github.com/rust-lang/rust/pull/58623
+[SwissTable]: https://abseil.io/blog/20180927-swisstables
+[pr-hashbrown-perf]: https://perf.rust-lang.org/compare.html?start=b57fe74a27590289fd657614b8ad1f3eac8a7ad2&end=abade53a649583e40ed07c26ee10652703f09b58&stat=wall-time
+
+In Rust 1.36.0, the `HashMap` implementation has been [replaced][pr-hashbrown]
+with the one in the [`hashbrown`] crate which is based on the [SwissTable] design.
+While the interface is the same, the `HashMap` implementation is now
+[faster on average][pr-hashbrown-perf] and has lower memory overhead.
+Note that unlike the `hashbrown` crate,
+the implementation in `std` still defaults to the SipHash 1-3 hashing algorithm.
+
+### [`--offline`] support in Cargo
+
+[`--offline`]: https://doc.rust-lang.org/cargo/commands/cargo-build.html#cargo_build_manifest_options
+[`cargo fetch`]: https://doc.rust-lang.org/cargo/commands/cargo-fetch.html
+[nrc-blog]: https://www.ncameron.org/blog/cargo-offline/
+[relnotes-cargo]: https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-136-2019-07-04
+
+During most builds, Cargo doesn't interact with the network.
+Sometimes, however, Cargo has to.
+Such is the case when a dependency is added and the latest compatible version needs to be downloaded.
+At times, network access is not an option though, for example on an airplane or in isolated build environments.
+
+In Rust 1.36, a new Cargo flag has been stabilized: [`--offline`].
+The flag alters Cargo's dependency resolution algorithm to only use locally cached dependencies.
+When the required crates are not available offline, and a network access would be required,
+Cargo will exit with an error.
+To prepopulate the local cache in preparation for going offline,
+use the [`cargo fetch`] command, which downloads all the required dependencies for a project.
+
+To find out more about [`--offline`] and [`cargo fetch`], read [Nick Cameron's blog post][nrc-blog].
+
+For information on other changes to Cargo, see the [detailed release notes][relnotes-cargo].
+
+### Library changes
+
+[`dbg!`]: https://doc.rust-lang.org/std/macro.dbg.html
+
+The [`dbg!`] macro now supports multiple arguments.
+
+Additionally, a number of APIs have been made `const`:
+
+[`Layout::from_size_align_unchecked`]: https://doc.rust-lang.org/core/alloc/struct.Layout.html#method.from_size_align_unchecked
+[`mem::needs_drop`]: https://doc.rust-lang.org/std/mem/fn.needs_drop.html
+[`NonNull::dangling`]: https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.dangling
+[`NonNull::cast`]: https://doc.rust-lang.org/std/ptr/struct.NonNull.html#method.cast
+
+- [`Layout::from_size_align_unchecked`]
+- [`mem::needs_drop`]
+- [`NonNull::dangling`]
+- [`NonNull::cast`]
+
+New APIs have become stable, including:
+
+[`Iterator::copied`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.copied
+[`VecDeque::rotate_left`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.rotate_left
+[`VecDeque::rotate_right`]: https://doc.rust-lang.org/std/collections/struct.VecDeque.html#method.rotate_right
+[`BorrowMut for String`]: https://github.com/rust-lang/rust/pull/60404
+[`str::as_mut_ptr`]: https://doc.rust-lang.org/std/primitive.str.html#method.as_mut_ptr
+[`pointer::align_offset`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.align_offset
+[`Read::read_vectored`]: https://doc.rust-lang.org/std/io/trait.Read.html#method.read_vectored
+[`Write::write_vectored`]: https://doc.rust-lang.org/std/io/trait.Write.html#method.write_vectored
+[`task::Waker`]: https://doc.rust-lang.org/std/task/struct.Waker.html
+[`task::Poll`]: https://doc.rust-lang.org/std/task/enum.Poll.html
+
+- [`task::Waker`] and [`task::Poll`]
+- [`VecDeque::rotate_left`] and [`VecDeque::rotate_right`]
+- [`Read::read_vectored`] and [`Write::write_vectored`]
+- [`Iterator::copied`]
+- [`BorrowMut for String`]
+- [`str::as_mut_ptr`]
+
+Other library changes are available in the [detailed release notes][notes].
+
+### Other changes
+
+[relnotes-clippy]: https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-136
+
+Detailed 1.36.0 release notes are available for [Rust][notes],
+[Cargo][relnotes-cargo], and [Clippy][relnotes-clippy].
+
+## Contributors to 1.36.0
+
+Many people came together to create Rust 1.36.0. We couldn't have done it
+without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.36.0/)
diff --git a/content/Rust-1.37.0.md b/content/Rust-1.37.0.md
new file mode 100644
index 000000000..c5ab2bed6
--- /dev/null
+++ b/content/Rust-1.37.0.md
@@ -0,0 +1,182 @@
++++
+path = "2019/08/15/Rust-1.37.0"
+title = "Announcing Rust 1.37.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/08/15/Rust-1.37.0.html",
+ "releases/1.37.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.37.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust 1.37.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate page on our website, and check out the [detailed release notes for 1.37.0][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1370-2019-08-15
+
+## What's in 1.37.0 stable
+
+The highlights of Rust 1.37.0 include referring to `enum` variants through `type` aliases, built-in `cargo vendor`, unnamed `const` items, profile-guided optimization, a `default-run` key in Cargo, and `#[repr(align(N))]` on `enum`s. Read on for a few highlights, or see the [detailed release notes][notes] for additional information.
+
+### Referring to `enum` variants through `type` aliases
+
+With Rust 1.37.0, you can now refer to `enum` variants through type aliases. For example:
+
+```rust
+type ByteOption = Option;
+
+fn increment_or_zero(x: ByteOption) -> u8 {
+ match x {
+ ByteOption::Some(y) => y + 1,
+ ByteOption::None => 0,
+ }
+}
+```
+
+In implementations, `Self` acts like a type alias. So in Rust 1.37.0, you can also refer to `enum` variants with `Self::Variant`:
+
+```rust
+impl Coin {
+ fn value_in_cents(&self) -> u8 {
+ match self {
+ Self::Penny => 1,
+ Self::Nickel => 5,
+ Self::Dime => 10,
+ Self::Quarter => 25,
+ }
+ }
+}
+```
+
+[type_rel_report]: https://github.com/rust-lang/rust/pull/61682/#issuecomment-502472847
+
+To be more exact, Rust now allows you to refer to `enum` variants through *"type-relative resolution"*, `>::Variant`. More details are available in [the stabilization report][type_rel_report].
+
+### Built-in Cargo support for vendored dependencies
+
+[vendor-crate]: https://crates.io/crates/cargo-vendor
+
+After being available [as a separate crate][vendor-crate] for years, the `cargo vendor` command is now integrated directly into Cargo. The command fetches all your project's dependencies unpacking them into the `vendor/` directory, and shows the configuration snippet required to use the vendored code during builds.
+
+There are multiple cases where `cargo vendor` is already used in production: the Rust compiler `rustc` uses it to ship all its dependencies in release tarballs, and projects with monorepos use it to commit the dependencies' code in source control.
+
+### Using unnamed `const` items for macros
+
+[unnamed_const_pr]: https://github.com/rust-lang/rust/pull/61347/
+
+You can now create [unnamed `const` items][unnamed_const_pr]. Instead of giving your constant an explicit name, simply name it `_` instead. For example, in the `rustc` compiler we find:
+
+```rust
+/// Type size assertion where the first parameter
+/// is a type and the second is the expected size.
+#[macro_export]
+macro_rules! static_assert_size {
+ ($ty:ty, $size:expr) => {
+ const _: [(); $size] = [(); ::std::mem::size_of::<$ty>()];
+ // ^ Note the underscore here.
+ }
+}
+
+static_assert_size!(Option>, 8); // 1.
+static_assert_size!(usize, 8); // 2.
+```
+
+Notice the second `static_assert_size!(..)`: thanks to the use of unnamed constants, you can define new items without naming conflicts. Previously you would have needed to write `static_assert_size!(MY_DUMMY_IDENTIFIER, usize, 8);`. Instead, with Rust 1.37.0, it now becomes easier to create ergonomic and reusable declarative and procedural macros for static analysis purposes.
+
+### Profile-guided optimization
+
+[rustc_book_pgo]: https://doc.rust-lang.org/rustc/profile-guided-optimization.html
+[pgo_pr]: https://github.com/rust-lang/rust/pull/61268/
+[pgo_wiki]: https://en.wikipedia.org/wiki/Profile-guided_optimization
+
+The `rustc` compiler now comes with [support for Profile-Guided Optimization (PGO)][pgo_pr] via the `-C profile-generate` and `-C profile-use` flags.
+
+[Profile-Guided Optimization][pgo_wiki] allows the compiler to optimize code based on feedback from real workloads. It works by compiling the program to optimize in two steps:
+
+1. First, the program is built with instrumentation inserted by the compiler. This is done by passing the `-C profile-generate` flag to `rustc`. The instrumented program then needs to be run on sample data and will write the profiling data to a file.
+2. Then, the program is built *again*, this time feeding the collected profiling data back into `rustc` by using the `-C profile-use` flag. This build will make use of the collected data to allow the compiler to make better decisions about code placement, inlining, and other optimizations.
+
+For more in-depth information on Profile-Guided Optimization, please refer to the corresponding [chapter in the rustc book][rustc_book_pgo].
+
+### Choosing a default binary in Cargo projects
+
+[`default-run`]: https://doc.rust-lang.org/cargo/reference/manifest.html#the-default-run-field
+[`cargo run`]: https://doc.rust-lang.org/cargo/commands/cargo-run.html
+
+[`cargo run`] is great for quickly testing CLI applications. When multiple binaries are present in the same package, you have to explicitly declare the name of the binary you want to run with the `--bin` flag. This makes `cargo run` not as ergonomic as we'd like, especially when a binary is called more often than the others.
+
+Rust 1.37.0 addresses the issue by adding [`default-run`], a new key in `Cargo.toml`. When the key is declared in the `[package]` section, `cargo run` will default to the chosen binary if the `--bin` flag is not passed.
+
+### `#[repr(align(N))]` on `enum`s
+
+[enum_align_pr]: https://github.com/rust-lang/rust/pull/61229
+[ref_align_mod]: https://doc.rust-lang.org/reference/type-layout.html#the-alignment-modifiers
+[ref_align_explain]: https://doc.rust-lang.org/reference/type-layout.html#size-and-alignment
+
+[The `#[repr(align(N))]` attribute][ref_align_mod] can be used to raise the [alignment][ref_align_explain] of a type definition. Previously, the attribute was only allowed on `struct`s and `union`s. With Rust 1.37.0, the attribute can now also be used [on `enum` definitions][enum_align_pr]. For example, the following type `Align16` would, as expected, report `16` as the alignment whereas the natural alignment without `#[repr(align(16))]` would be `4`:
+
+```rust
+#[repr(align(16))]
+enum Align16 {
+ Foo { foo: u32 },
+ Bar { bar: u32 },
+}
+```
+
+The semantics of using `#[repr(align(N))` on an `enum` is the same as defining a wrapper struct `AlignN` with that alignment and then using `AlignN`:
+
+```rust
+#[repr(align(N))]
+struct AlignN(T);
+```
+
+### Library changes
+
+[`BufReader::buffer`]: https://doc.rust-lang.org/std/io/struct.BufReader.html#method.buffer
+[`BufWriter::buffer`]: https://doc.rust-lang.org/std/io/struct.BufWriter.html#method.buffer
+[`Cell::from_mut`]: https://doc.rust-lang.org/std/cell/struct.Cell.html#method.from_mut
+[`Cell::as_slice_of_cells`]: https://doc.rust-lang.org/std/cell/struct.Cell.html#method.as_slice_of_cells
+[`DoubleEndedIterator::nth_back`]: https://doc.rust-lang.org/std/iter/trait.DoubleEndedIterator.html#method.nth_back
+[`Option::xor`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.xor
+[`Wrapping::reverse_bits`]: https://doc.rust-lang.org/std/num/struct.Wrapping.html#method.reverse_bits
+[`{i,u}{8,16,32,64,128,size}::reverse_bits`]: https://doc.rust-lang.org/std/primitive.u8.html#method.reverse_bits
+[`slice::copy_within`]: https://doc.rust-lang.org/std/primitive.slice.html#method.copy_within
+
+In Rust 1.37.0 there have been a number of standard library stabilizations:
+
+- [`BufReader::buffer`] and [`BufWriter::buffer`]
+- [`Cell::from_mut`]
+- [`Cell::as_slice_of_cells`]
+- [`DoubleEndedIterator::nth_back`]
+- [`Option::xor`]
+- [`{i,u}{8,16,32,64,128,size}::reverse_bits`] and [`Wrapping::reverse_bits`]
+- [`slice::copy_within`]
+
+### Other changes
+
+[relnotes-cargo]: https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-137-2019-08-15
+[relnotes-clippy]: https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-137
+
+There are other changes in the Rust 1.37 release: check out what changed in [Rust][notes], [Cargo][relnotes-cargo], and [Clippy][relnotes-clippy].
+
+## Contributors to 1.37.0
+
+Many people came together to create Rust 1.37.0. We couldn't have done it
+without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.37.0/)
+
+## New sponsors of Rust infrastructure
+
+We'd like to thank two new sponsors of Rust's infrastructure who provided the resources needed to make Rust 1.37.0 happen: Amazon Web Services (AWS) and Microsoft Azure.
+
+- AWS has provided hosting for release artifacts (compilers, libraries, tools, and source code), serving those artifacts to users through CloudFront, preventing regressions with Crater on EC2, and managing other Rust-related infrastructure hosted on AWS.
+- Microsoft Azure has sponsored builders for Rust’s CI infrastructure, notably the extremely resource intensive rust-lang/rust repository.
diff --git a/content/Rust-1.38.0.md b/content/Rust-1.38.0.md
new file mode 100644
index 000000000..b81fc65a5
--- /dev/null
+++ b/content/Rust-1.38.0.md
@@ -0,0 +1,149 @@
++++
+path = "2019/09/26/Rust-1.38.0"
+title = "Announcing Rust 1.38.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/09/26/Rust-1.38.0.html",
+ "releases/1.38.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.38.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust 1.38.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate page on our website.
+
+[install]: https://www.rust-lang.org/install.html
+
+## What's in 1.38.0 stable
+
+The highlight of this release is pipelined compilation.
+
+### Pipelined compilation
+
+[internals-pipelined]: https://internals.rust-lang.org/t/evaluating-pipelined-rustc-compilation/10199
+
+To compile a crate, the compiler doesn't need the dependencies to be fully built. Instead, it just needs their "metadata" (i.e. the list of types, dependencies, exports...). This metadata is produced early in the compilation process. Starting with Rust 1.38.0, Cargo will take advantage of this by automatically starting to build dependent crates as soon as metadata is ready.
+
+While the change doesn't have any effect on builds for a single crate, during testing [we got reports][internals-pipelined] of 10-20% compilation speed increases for optimized, clean builds of some crate graphs. Other ones did not improve much, and the speedup depends on the hardware running the build, so your mileage might vary. No code changes are needed to benefit from this.
+
+### Linting some incorrect uses of `mem::{uninitialized, zeroed}`
+
+As [previously announced](https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#maybeuninitt%3E-instead-of-mem::uninitialized), `std::mem::uninitialized` is essentially impossible to use safely. Instead, `MaybeUninit` should be used.
+
+We have not yet deprecated `mem::uninitialized`; this will be done in a future release. Starting in 1.38.0, however, `rustc` will provide a lint for a narrow class of incorrect initializations using `mem::uninitialized` or `mem::zeroed`.
+
+It is undefined behavior for some types, such as `&T` and `Box`, to ever contain an all-`0` bit pattern, because they represent pointer-like objects that cannot be `null`. It is therefore an error to use `mem::uninitialized` or `mem::zeroed` to initialize one of these types, so the new lint will attempt to warn whenever one of those functions is used to initialize one of them, either directly or as a member of a larger `struct`. The check is recursive, so the following code will emit a warning:
+
+```rust
+struct Wrap(T);
+struct Outer(Wrap>>>);
+struct CannotBeZero {
+ outer: Outer,
+ foo: i32,
+ bar: f32
+}
+
+...
+
+let bad_value: CannotBeZero = unsafe { std::mem::uninitialized() };
+```
+
+Astute readers may note that Rust has more types that cannot be zero, notably `NonNull` and `NonZero`. For now, initialization of these structs with `mem::uninitialized` or `mem::zeroed` is *not* linted against.
+
+These checks do not cover all cases of unsound use of `mem::uninitialized` or `mem::zeroed`, they merely help identify code that is definitely wrong. All code should still be moved to use `MaybeUninit` instead.
+
+### `#[deprecated]` macros
+
+The `#[deprecated]` attribute, first introduced in Rust 1.9.0, allows crate authors to notify their users an item of their crate is deprecated and will be removed in a future release. Rust 1.38.0 extends the attribute, allowing it to be applied to macros as well.
+
+### `std::any::type_name`
+
+For debugging, it is sometimes useful to get the name of a type. For instance, in generic code, you may want to see, at run-time, what concrete types a function's type parameters has been instantiated with. This can now be done using `std::any::type_name`:
+
+```rust
+fn gen_value() -> T {
+ println!("Initializing an instance of {}", std::any::type_name::());
+ Default::default()
+}
+
+fn main() {
+ let _: i32 = gen_value();
+ let _: String = gen_value();
+}
+```
+
+This prints:
+
+```
+Initializing an instance of i32
+Initializing an instance of alloc::string::String
+```
+
+Like all standard library functions intended only for debugging, the exact contents and format of the string are not guaranteed. The value returned is only a best-effort description of the type; multiple types may share the same `type_name` value, and the value may change in future compiler releases.
+
+### Library changes
+
+- [`slice::{concat, connect, join}` now accepts `&[T]` in addition to `&T`.][62528]
+- [`*const T` and `*mut T` now implement `marker::Unpin`.][62583]
+- [`Arc<[T]>` and `Rc<[T]>` now implement `FromIterator`.][61953]
+- [`iter::{StepBy, Peekable, Take}` now implement `DoubleEndedIterator`.][61457]
+
+Additionally, these functions have been stabilized:
+
+- [`<*const T>::cast`] and [`<*mut T>::cast`]
+- [`Duration::as_secs_f32`] and [`Duration::as_secs_f64`]
+- [`Duration::div_f32`] and [`Duration::div_f64`]
+- [`Duration::from_secs_f32`] and [`Duration::from_secs_f64`]
+- [`Duration::mul_f32`] and [`Duration::mul_f64`]
+- Euclidean remainder and division operations -- [`div_euclid`],
+ [`rem_euclid`] -- for all integer primitives. `checked`,
+ `overflowing`, and `wrapping` versions are also available.
+
+[`<*const T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast
+[`<*mut T>::cast`]: https://doc.rust-lang.org/std/primitive.pointer.html#method.cast-1
+[`Duration::as_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f32
+[`Duration::as_secs_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.as_secs_f64
+[`Duration::div_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f32
+[`Duration::div_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_f64
+[`Duration::from_secs_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f32
+[`Duration::from_secs_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.from_secs_f64
+[`Duration::mul_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f32
+[`Duration::mul_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.mul_f64
+[`div_euclid`]: https://doc.rust-lang.org/std/primitive.i32.html#method.div_euclid
+[`rem_euclid`]: https://doc.rust-lang.org/std/primitive.i32.html#method.rem_euclid
+
+
+[62528]: https://github.com/rust-lang/rust/pull/62528/
+[62583]: https://github.com/rust-lang/rust/pull/62583/
+[61953]: https://github.com/rust-lang/rust/pull/61953/
+[61884]: https://github.com/rust-lang/rust/pull/61884/
+[61457]: https://github.com/rust-lang/rust/pull/61457/
+
+### Other changes
+
+[relnotes-rust]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1380-2019-09-26
+[relnotes-cargo]: https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-138-2019-09-26
+[relnotes-clippy]: https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-138
+
+There are other changes in the Rust 1.38 release: check out what changed in [Rust][relnotes-rust], [Cargo][relnotes-cargo], and [Clippy][relnotes-clippy].
+
+### Corrections
+A Previous version of this post mistakenly marked these functions as stable. They are not yet stable.
+[`Duration::div_duration_f32`] and [`Duration::div_duration_f64`].
+
+[`Duration::div_duration_f32`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f32
+[`Duration::div_duration_f64`]: https://doc.rust-lang.org/std/time/struct.Duration.html#method.div_duration_f64
+
+## Contributors to 1.38.0
+
+Many people came together to create Rust 1.38.0. We couldn't have done it
+without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.38.0/)
diff --git a/content/Rust-1.39.0.md b/content/Rust-1.39.0.md
new file mode 100644
index 000000000..e81a43c4f
--- /dev/null
+++ b/content/Rust-1.39.0.md
@@ -0,0 +1,177 @@
++++
+path = "2019/11/07/Rust-1.39.0"
+title = "Announcing Rust 1.39.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/11/07/Rust-1.39.0.html",
+ "releases/1.39.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.39.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust 1.39.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate page on our website, and check out the [detailed release notes for 1.39.0][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1390-2019-11-07
+
+## What's in 1.39.0 stable
+
+The highlights of Rust 1.39.0 include `async`/`.await`, shared references to by-move bindings in `match` guards, and attributes on function parameters. Also, see the [detailed release notes][notes] for additional information.
+
+### The `.await` is over, `async fn`s are here
+
+[rel-1360]: https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#the-future-is-here
+[`Future`]: https://doc.rust-lang.org/nightly/std/future/trait.Future.html
+[niko-post-async]: https://blog.rust-lang.org/2019/11/07/Async-await-stable.html
+
+Previously in Rust 1.36.0, [we announced][rel-1360] that the [`Future`] trait is here. Back then, we noted that:
+
+> With this stabilization, we hope to give important crates, libraries, and the ecosystem time to prepare for `async` / `.await`, which we'll tell you more about in the future.
+
+A promise made is a promise kept. So in Rust 1.39.0, we are pleased to announce that `async` / `.await` is stabilized! Concretely, this means that you can define `async` functions and blocks and `.await` them.
+
+An `async` function, which you can introduce by writing `async fn` instead of `fn`, does nothing other than to return a `Future` when called. This `Future` is a suspended computation which you can drive to completion by `.await`ing it. Besides `async fn`, `async { ... }` and `async move { ... }` blocks, which act like closures, can be used to define "async literals".
+
+For more on the release of `async` / `.await`, read [Niko Matsakis's blog post][niko-post-async].
+
+### References to by-move bindings in `match` guards
+
+[pr-bind-by-move]: https://github.com/rust-lang/rust/pull/63118/#issuecomment-522823925
+
+When pattern matching in Rust, a variable, also known as a "binding", can be bound in the following ways:
+
+- by-reference, either immutably or mutably. This can be achieved explicitly e.g. through `ref my_var` or `ref mut my_var` respectively. Most of the time though, the binding mode will be inferred automatically.
+
+- by-value -- either by-copy, when the bound variable's type implements `Copy`, or otherwise **_by-move_**.
+
+Previously, Rust would forbid taking shared references to **_by-move_** bindings in the `if` guards of `match` expressions. This meant that the following code would be rejected:
+
+```rust
+fn main() {
+ let array: Box<[u8; 4]> = Box::new([1, 2, 3, 4]);
+
+ match array {
+ nums
+// ---- `nums` is bound by move.
+ if nums.iter().sum::() == 10
+// ^------ `.iter()` implicitly takes a reference to `nums`.
+ => {
+ drop(nums);
+// ----------- `nums` was bound by move and so we have ownership.
+ }
+ _ => unreachable!(),
+ }
+}
+```
+
+[With Rust 1.39.0][pr-bind-by-move], the snippet above is now accepted by the compiler. We hope that this will give a smoother and more consistent experience with `match` expressions overall.
+
+### Attributes on function parameters
+
+[pr-attr]: https://github.com/rust-lang/rust/pull/64010/
+
+With Rust 1.39.0, attributes are now allowed on parameters of functions, closures, and function pointers. Whereas before, you might have written:
+
+```rust
+#[cfg(windows)]
+fn len(slice: &[u16]) -> usize {
+ slice.len()
+}
+#[cfg(not(windows))]
+fn len(slice: &[u8]) -> usize {
+ slice.len()
+}
+```
+
+...[you can now][pr-attr], more succinctly, write:
+
+```rust
+fn len(
+ #[cfg(windows)] slice: &[u16], // This parameter is used on Windows.
+ #[cfg(not(windows))] slice: &[u8], // Elsewhere, this one is used.
+) -> usize {
+ slice.len()
+}
+```
+
+The attributes you can use in this position include:
+
+1. Conditional compilation: `cfg` and `cfg_attr`
+
+2. Controlling lints: `allow`, `warn`, `deny`, and `forbid`
+
+3. Helper attributes used by procedural macro attributes applied to items.
+
+ Our hope is that this will be used to provide more readable and ergonomic macro-based DSLs throughout the ecosystem.
+
+### Borrow check migration warnings are hard errors in Rust 2018
+
+[rel-1360-nll]: https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#nll-for-rust-2015
+[rel-1310]: https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes
+[err-2018]: https://github.com/rust-lang/rust/pull/63565
+[err-2015]: https://github.com/rust-lang/rust/pull/64221
+[rip-ast-borrowck]: https://github.com/rust-lang/rust/pull/64790
+[niko-blog-nll]: https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html
+
+In the 1.36.0 release, [we announced][rel-1360-nll] that NLL had come to Rust 2015 after first being released for Rust 2018 in [1.31][rel-1310].
+
+As noted in the 1.36.0 release, the old borrow checker had some bugs which would allow memory unsafety. These bugs were fixed by the NLL borrow checker. As these fixes broke some stable code, we decided to gradually phase in the errors by checking if the old borrow checker would accept the program and the NLL checker would reject it. If so, the errors would instead become warnings.
+
+With Rust 1.39.0, these warnings are now [errors in Rust 2018][err-2018].
+In the next release, Rust 1.40.0, [this will also apply to Rust 2015][err-2015], which will finally allow us to [remove the old borrow checker][rip-ast-borrowck], and keep the compiler clean.
+
+If you are affected, or want to hear more, read [Niko Matsakis's blog post][niko-blog-nll].
+
+### More `const fn`s in the standard library
+
+[`Vec::new`]: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.new
+[`String::new`]: https://doc.rust-lang.org/std/string/struct.String.html#method.new
+[`LinkedList::new`]: https://doc.rust-lang.org/std/collections/linked_list/struct.LinkedList.html#method.new
+[`str::len`]: https://doc.rust-lang.org/std/primitive.str.html#method.len
+[`slice::len`]: https://doc.rust-lang.org/std/primitive.slice.html#method.len
+[`str::as_bytes`]: https://doc.rust-lang.org/std/primitive.str.html#method.as_bytes
+[`abs`]: https://doc.rust-lang.org/std/primitive.i8.html#method.abs
+[`wrapping_abs`]: https://doc.rust-lang.org/std/primitive.i8.html#method.wrapping_abs
+[`overflowing_abs`]: https://doc.rust-lang.org/std/primitive.i8.html#method.overflowing_abs
+
+With Rust 1.39.0, the following functions became `const fn`:
+
+- [`Vec::new`], [`String::new`], and [`LinkedList::new`]
+- [`str::len`], [`[T]::len`][`slice::len`], and [`str::as_bytes`]
+- [`abs`], [`wrapping_abs`], and [`overflowing_abs`]
+
+### Additions to the standard library
+
+[`Pin::into_inner`]: https://doc.rust-lang.org/std/pin/struct.Pin.html#method.into_inner
+[`Instant::checked_duration_since`]: https://doc.rust-lang.org/std/time/struct.Instant.html#method.checked_duration_since
+[`Instant::saturating_duration_since`]: https://doc.rust-lang.org/std/time/struct.Instant.html#method.saturating_duration_since
+
+In Rust 1.39.0 the following functions were stabilized:
+
+- [`Pin::into_inner`]
+- [`Instant::checked_duration_since`] and [`Instant::saturating_duration_since`]
+
+### Other changes
+
+[relnotes-cargo]: https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-139-2019-11-07
+[relnotes-clippy]: https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-139
+[compat-notes]: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#compatibility-notes
+
+There are other changes in the Rust 1.39.0 release: check out what changed in [Rust][notes], [Cargo][relnotes-cargo], and [Clippy][relnotes-clippy].
+
+Please also see the [compatibility notes][compat-notes] to check if you're affected by those changes.
+
+## Contributors to 1.39.0
+
+Many people came together to create Rust 1.39.0. We couldn't have done it
+without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.39.0/)
diff --git a/content/Rust-1.4.md b/content/Rust-1.4.md
new file mode 100644
index 000000000..72b624979
--- /dev/null
+++ b/content/Rust-1.4.md
@@ -0,0 +1,231 @@
++++
+path = "2015/10/29/Rust-1.4"
+title = "Announcing Rust 1.4"
+authors = ["The Rust Core Team"]
+aliases = [
+ "2015/10/29/Rust-1.4.html",
+ "releases/1.4.0",
+]
+
+[extra]
+release = true
++++
+
+Choo choo! The trains have kept rolling, and today, we’re happy to announce the
+release of Rust 1.4, the newest stable release. Rust is a systems programming
+language focused on safety, speed, and concurrency.
+
+As always, you can [install Rust 1.4][install] from the appropriate page on our
+website, and check out the [detailed release notes for 1.4][notes] on GitHub as
+well. About 1200 patches were landed in this release.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/8ab8581f6921bc7a8e3fa4defffd2814372dcb15/RELEASES.md#version-140-october-2015
+
+### What's in 1.4 stable
+
+The story of 1.4 is mostly one of improvements and stabilizations, rather than
+new features.
+
+However, there is one particular change which is a language fix that enables a
+new feature: [RFC 1214, “Clarify (and improve) rules for projections and
+well-formedness”](https://github.com/rust-lang/rfcs/pull/1214). While that’s
+a deeply technical title, the TL;DR is that we found some weaknesses in the
+definition and implementation of a few aspects of the type system. This RFC
+fixes these problems. Given that changes to the type system like this can cause
+regressions, but fixes like this are important for soundness, Rust 1.4 will
+warn on any code that violates the new rules, but still compile. These warnings
+will turn into errors in Rust 1.5. However, given the train model, the
+community has had time to deal with these changes while 1.4 was in beta, and
+the small number of crates we were aware of have already been fixed.
+
+These soundness fixes enable the return of the ‘scoped threads’ feature, in
+which you can create threads that reference data stored on the stack in a
+safe manner. A few crates have implemented this feature, most notably
+[crossbeam] and [scoped_threadpool]. See their documentation for more
+information.
+
+[crossbeam]: https://crates.io/crates/crossbeam
+[scoped_threadpool]: https://crates.io/crates/scoped_threadpool
+
+[RFC 1212](https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md)
+is also in this release, which changes all functions dealing with reading
+‘lines’ to treat both `\n` and `\r\n` as a valid line-ending. This was
+determined during the RFC process to be a bugfix, but we’re mentioning it
+here to raise awareness. The older behavior of only dealing with `\n` made
+for surprising behavior, where your crate would work well on Linux and Mac OS
+X, but fail on Windows. This fix brings these functions more in-line (😉)
+with expectations.
+
+Rust 1.4 marks an upgrade in our Windows support: Windows builds targeting the
+64-bit MSVC ABI and linker (instead of GNU) are now supported and recommended
+for general use, and will appear on the downloads page for the first time.
+Thank you to all who have helped us work out the kinks since support initially
+landed in Rust 1.2.
+
+Here’s a summary of library changes:
+
+* 48 APIs were stabilized.
+* Eight APIs were deprecated.
+* Two were made faster.
+* Over ten various types implement new traits.
+
+See the [release notes][libnotes] for exact details.
+
+[libnotes]: https://github.com/brson/rust/blob/relnotes/RELEASES.md#libraries
+
+The compiler [no longer uses
+`morestack`](https://github.com/rust-lang/rust/pull/27338), which was a
+holdover implementation detail from long, long ago. We now use guard pages
+and stack probes instead, though stack probes are only implemented on Windows
+so far.
+
+Finally, one major Cargo improvement: [`cargo update` will now print extra
+information about what it is
+changing.](https://github.com/rust-lang/cargo/pull/1931) For example:
+
+```
+$ cargo update
+ Updating registry `https://github.com/rust-lang/crates.io-index`
+ Updating libc v0.1.8 -> v0.1.10
+ Updating memchr v0.1.3 -> v0.1.5
+ Updating num v0.1.26 -> v0.1.27
+ Updating rand v0.3.9 -> v0.3.10
+ Updating rustc-serialize v0.3.15 -> v0.3.16
+```
+
+Before, it would do this job silently.
+
+### Contributors to 1.4
+
+Rust is a community-driven project, and we're very appreciative of the work of
+the 127 contributors who made 1.4 happen. Thank you!
+
+- Adam Crume
+- Aidan Hobson Sayers
+- Aleksey Kladov
+- Alex Burka
+- Alex Crichton
+- Alex Ozdemir
+- AlexDenisov
+- Alexis Beingessner
+- Alisdair Owens
+- Andre Bogus
+- Andrea Canciani
+- Andrew Paseltiner
+- Ariel Ben-Yehuda
+- Artem Shitov
+- Barosl Lee
+- benshu
+- Björn Steinbrink
+- bors
+- Brian Anderson
+- Cesar Eduardo Barros
+- Chris Krycho
+- Chris Morgan
+- Chris Nixon
+- Chris Wong
+- christopherdumas
+- Cody P Schafer
+- Corey Farwell
+- Daan Rijks
+- Dave Huseby
+- diaphore
+- Diggory Blake
+- Dong Zhou
+- Dylan McKay
+- Elaine "See More" Nemo
+- Eli Friedman
+- Eljay
+- Erick Tryzelaar
+- Felix S. Klock II
+- Garming Sam
+- Georg Brandl
+- Gleb Kozyrev
+- Guillaume Gomez
+- Hunan Rostomyan
+- Huon Wilson
+- Ivan Jager
+- Jack Wilson
+- Jake Goulding
+- Jake Kerr
+- Jake Shadle
+- James Miller
+- Jan Likar
+- Jared Roesch
+- Jeehoon Kang
+- John Thomas
+- Jonas Schievink
+- Jørn Lode
+- Jose Narvaez
+- jotomicron
+- Kang Seonghoon
+- Kornel Lesiński
+- Lee Jeffery
+- Leif Arne Storset
+- Lennart Kudling
+- llogiq
+- Manish Goregaokar
+- Marc-Antoine Perennou
+- Marcus Klaas
+- Marko Lalic
+- Martin Wernstål
+- Matěj Grabovský
+- Matej Lach
+- Matt Brubeck
+- Matt Friedman
+- Michael Choate
+- Michael Layzell
+- Michael Macias
+- Michael McConville
+- Michael Neumann
+- Mickaël Salaün
+- midinastasurazz
+- Mike Marcacci
+- mitaa
+- Ms2ger
+- Murarth
+- Nathan Kleyn
+- Nicholas Seckar
+- Nick Cameron
+- Nick Howell
+- Niko Matsakis
+- Nikolay Kondratyev
+- Niranjan Padmanabhan
+- Overmind JIANG
+- Pascal Hertleif
+- Peter Reid
+- Remi Rampin
+- Richard Diamond
+- Robin Kruppe
+- Ruby
+- Ryo Munakata
+- Scott Olson
+- Sean Bowe
+- Sean McArthur
+- Sébastien Marie
+- Simon Mazur
+- Simon Sapin
+- Simonas Kazlauskas
+- Stepan Koltsov
+- Steve Klabnik
+- Steven Fackler
+- Sylvestre Ledru
+- Taliesin Beynon
+- Tamir Duberstein
+- Tim Cuthbertson
+- Tim JIANG
+- Tim Neumann
+- Tobias Bucher
+- Tshepang Lekhonkhobe
+- Ulrik Sverdrup
+- Vadim Chugunov
+- Vadim Petrochenkov
+- Viacheslav Chimishuk
+- Victor Berger
+- Vincent Bernat
+- Vladimir Rutsky
+- w00ns
+- William Throwe
+- Without Boats
+- Xiao Chuan Yu
diff --git a/content/Rust-1.40.0.md b/content/Rust-1.40.0.md
new file mode 100644
index 000000000..6bd51084a
--- /dev/null
+++ b/content/Rust-1.40.0.md
@@ -0,0 +1,258 @@
++++
+path = "2019/12/19/Rust-1.40.0"
+title = "Announcing Rust 1.40.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2019/12/19/Rust-1.40.0.html",
+ "releases/1.40.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.40.0. Rust is a programming language that is empowering everyone to build reliable and efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust 1.40.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the appropriate page on our website, and check out the [detailed release notes for 1.40.0][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1400-2019-12-19
+
+## What's in 1.40.0 stable
+
+The highlights of Rust 1.40.0 include `#[non_exhaustive]` and improvements to `macros!()` and `#[attribute]`s. Finally, borrow-check migration warnings have become hard errors in Rust 2015. See the [detailed release notes][notes] for additional information.
+
+### `#[non_exhaustive]` structs, enums, and variants
+
+[`Ordering`]: https://doc.rust-lang.org/std/sync/atomic/enum.Ordering.html
+[report_non_exhaustive]: https://github.com/rust-lang/rust/issues/44109#issuecomment-533356866
+
+Suppose you're a library author of a crate `alpha`, that has a `pub struct Foo`. You would like to make `alpha::Foo`'s fields `pub` as well, but you're not sure whether you might be adding more fields to `Foo` in future releases. So now you have a dilemma: either you make the fields private, with the drawbacks that follow, or you risk users depending on the exact fields, breaking their code when you add a new one. Rust 1.40.0 introduces a way to break the logjam: `#[non_exhaustive]`.
+
+The attribute `#[non_exhaustive]`, when attached to a `struct` or the variant of an `enum`, will prevent code outside of the crate defining it from constructing said `struct` or variant. To avoid future breakage, other crates are also prevented from exhaustively matching on the fields. The following example illustrates errors in `beta` which depends on `alpha`:
+
+```rust
+// alpha/lib.rs:
+
+#[non_exhaustive]
+struct Foo {
+ pub a: bool,
+}
+
+enum Bar {
+ #[non_exhaustive]
+ Variant { b: u8 }
+}
+
+fn make_foo() -> Foo { ... }
+fn make_bar() -> Bar { ... }
+
+// beta/lib.rs:
+
+let x = Foo { a: true }; //~ ERROR
+let Foo { a } = make_foo(); //~ ERROR
+
+// `beta` will still compile when more fields are added.
+let Foo { a, .. } = make_foo(); //~ OK
+
+
+let x = Bar::Variant { b: 42 }; //~ ERROR
+let Bar::Variant { b } = make_bar(); //~ ERROR
+let Bar::Variant { b, .. } = make_bar(); //~ OK
+ // -- `beta` will still compile...
+```
+
+What happens behind the scenes is that the visibility of the constructors for a `#[non_exhaustive]` `struct` or `enum` variant is lowered to `pub(crate)`, preventing access outside the crate defining it.
+
+A perhaps more important aspect of `#[non_exhaustive]` is that it can also be attached to `enum`s themselves. An example, taken from the standard library, is [`Ordering`]:
+
+```rust
+#[non_exhaustive]
+pub enum Ordering { Relaxed, Release, Acquire, AcqRel, SeqCst }
+```
+
+The purpose of `#[non_exhaustive]` in this context is to ensure that more variants can be added over time. This is achieved by preventing other crates from exhaustively pattern `match`-ing on `Ordering`. That is, the compiler would reject:
+
+```rust
+match ordering {
+ // This is an error, since if a new variant is added,
+ // this would suddenly break on an upgrade of the compiler.
+ Relaxed | Release | Acquire | AcqRel | SeqCst => {
+ /* logic */
+ }
+}
+```
+
+Instead, other crates need to account for the possibility of more variants by adding a wildcard arm using e.g. `_`:
+```rust
+match ordering {
+ Relaxed | Release | Acquire | AcqRel | SeqCst => { /* ... */ }
+ // OK; if more variants are added, nothing will break.
+ _ => { /* logic */ }
+}
+```
+
+For more details on the `#[non_exhaustive]` attribute, see the [stabilization report][report_non_exhaustive].
+
+### Macro and attribute improvements
+
+[pr_bang_proc_type]: https://github.com/rust-lang/rust/pull/63931/#issuecomment-526362396
+[pr_bang_extern]: https://github.com/rust-lang/rust/pull/63931/#issuecomment-526362396
+[ref_extern_block]: https://doc.rust-lang.org/nightly/reference/items/external-blocks.html
+[pr_mr_proc]: https://github.com/rust-lang/rust/pull/64035#issuecomment-533890826
+[pr_meta]: https://github.com/rust-lang/rust/pull/63674
+[pr_modern_syn]: https://github.com/rust-lang/rust/pull/57367#issuecomment-457882109
+
+In 1.40.0, we have introduced several improvements to macros and attributes, including:
+
+- [Calling procedural macros `mac!()` in type contexts.][pr_bang_proc_type]
+
+ For example, you may write `type Foo = expand_to_type!(bar);` where `expand_to_type` would be a procedural macro.
+
+- [Macros in `extern { ... }` blocks.][pr_bang_extern]
+
+ This includes `bang!()` macros, for example:
+ ```rust
+ macro_rules! make_item { ($name:ident) => { fn $name(); } }
+
+ extern {
+ make_item!(alpha);
+ make_item!(beta);
+ }
+ ```
+
+ Procedural macro attributes on items in [`extern { ... }` blocks][ref_extern_block] are now also supported:
+ ```rust
+ extern "C" {
+ // Let's assume that this expands to `fn foo();`.
+ #[my_identity_macro]
+ fn foo();
+ }
+ ```
+
+- [Generating `macro_rules!` items in procedural macros.][pr_mr_proc]
+
+ Function-like (`mac!()`) and attribute (`#[mac]`) macros can both now generate `macro_rules!` items. For details on hygiene, please refer to the attached stabilization report.
+
+- [The `$m:meta` matcher][pr_meta] supports [arbitrary token-stream values][pr_modern_syn].
+
+ That is, the following is now valid:
+
+ ```rust
+ macro_rules! accept_meta { ($m:meta) => {} }
+ accept_meta!( my::path );
+ accept_meta!( my::path = "lit" );
+ accept_meta!( my::path ( a b c ) );
+ accept_meta!( my::path [ a b c ] );
+ accept_meta!( my::path { a b c } );
+ ```
+
+### Borrow check migration warnings are hard errors in Rust 2015
+
+[rel-1350]: https://blog.rust-lang.org/2019/07/04/Rust-1.36.0.html#nll-for-rust-2015
+[rel-1310]: https://blog.rust-lang.org/2018/12/06/Rust-1.31-and-rust-2018.html#non-lexical-lifetimes
+[err-2018]: https://github.com/rust-lang/rust/pull/63565
+[err-2015]: https://github.com/rust-lang/rust/pull/64221
+[rip-ast-borrowck]: https://github.com/rust-lang/rust/pull/64790
+[niko-blog-nll]: https://blog.rust-lang.org/2019/11/01/nll-hard-errors.html
+
+In the 1.35.0 release, [we announced][rel-1350] that NLL had come to Rust 2015 after first being released for the 2018 edition in [Rust 1.31][rel-1310].
+
+As we noted back then, the old borrow checker had some bugs which would allow memory unsafety, and the NLL borrow checker fixed them. As these fixes break some stable code, we decided to gradually phase in the errors, by checking if the old borrow checker would accept the program and the NLL checker would reject it. In those cases, the errors would be downgraded to warnings.
+
+The previous release, Rust 1.39.0, changes these warnings into errors for code using the [2018 edition][err-2018]. Rust 1.40.0 applies the same change for users of the [2015 edition][err-2015], closing those soundness holes for good. This also allows us to [clean up the old code from the compiler][rip-ast-borrowck].
+
+If your build breaks due to this change, or you want to learn more, check out [Niko Matsakis's blog post][niko-blog-nll].
+
+### More `const fn`s in the standard library
+
+[pr_is_power_of_two]: https://github.com/rust-lang/rust/pull/65092
+[`is_power_of_two`]: https://doc.rust-lang.org/std/primitive.u8.html#method.is_power_of_two
+
+With Rust 1.40.0, the following function became `const fn`:
+
+- [`is_power_of_two`] for [unsigned integers][pr_is_power_of_two]
+
+### Additions to the standard library
+
+[`todo!()`]: https://doc.rust-lang.org/std/macro.todo.html
+[`mem::take`]: https://doc.rust-lang.org/std/mem/fn.take.html
+[`slice::repeat`]: https://doc.rust-lang.org/std/primitive.slice.html#method.repeat
+[`BTreeMap::get_key_value`]: https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.get_key_value
+[`HashMap::get_key_value`]: https://doc.rust-lang.org/std/collections/struct.HashMap.html#method.get_key_value
+[`Option::flatten`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.flatten
+[`Option::as_deref`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.as_deref
+[`Option::as_deref_mut`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.as_deref_mut
+[`UdpSocket::peer_addr`]: https://doc.rust-lang.org/std/net/struct.UdpSocket.html#method.peer_addr
+[`{f32,f64}::to_be_bytes`]: https://doc.rust-lang.org/std/primitive.f32.html#method.to_be_bytes
+[`{f32,f64}::to_le_bytes`]: https://doc.rust-lang.org/std/primitive.f32.html#method.to_le_bytes
+[`{f32,f64}::to_ne_bytes`]: https://doc.rust-lang.org/std/primitive.f32.html#method.to_ne_bytes
+[`{f32,f64}::from_be_bytes`]: https://doc.rust-lang.org/std/primitive.f32.html#method.from_be_bytes
+[`{f32,f64}::from_le_bytes`]: https://doc.rust-lang.org/std/primitive.f32.html#method.from_le_bytes
+[`{f32,f64}::from_ne_bytes`]: https://doc.rust-lang.org/std/primitive.f32.html#method.from_ne_bytes
+
+[`Option::take`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.take
+[`Cell::take`]: https://doc.rust-lang.org/std/cell/struct.Cell.html#method.take
+[`mem::replace`]: https://doc.rust-lang.org/std/mem/fn.replace.html
+[`unimplemented!()`]: https://doc.rust-lang.org/std/macro.unimplemented.html
+[`Option::flatten`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.flatten
+[`Option::as_ref`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.as_ref
+[`Option::as_mut`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.as_mut
+[`Deref`]: https://doc.rust-lang.org/std/ops/trait.Deref.html
+[`DerefMut`]: https://doc.rust-lang.org/std/ops/trait.DerefMut.html
+[`Iterator::flatten`]: https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.flatten
+
+In Rust 1.40.0 the following functions and macros were stabilized:
+
+- [`todo!()`]
+
+ A macro, which is a shorter, more memorable, and convenient version of [`unimplemented!()`].
+
+- [`slice::repeat`]
+
+ Creates a `Vec` by repeating a slice `n` times.
+
+- [`mem::take`]
+
+ This function `take`s the value out of a mutable reference and replaces it with the type's default. This is similar to [`Option::take`] and [`Cell::take` ] and provides a convenient short-hand for [`mem::replace(&mut dst, Default::default())`][`mem::replace`].
+
+- [`BTreeMap::get_key_value`] and [`HashMap::get_key_value`]
+
+ Returns the key-value pair corresponding to the supplied key.
+
+- [`Option::as_deref`], [`Option::as_deref_mut`]
+
+ These work similarly to [`Option::as_ref`] and [`Option::as_mut`] but also use [`Deref`] and [`DerefMut`] respectively, so that `opt_box.as_deref()` and `opt_box.as_deref_mut()`, where `opt_box: Option>`, produce an `Option<&T>` and `Option<&mut T>` respectively.
+
+- [`Option::flatten`]
+
+ This function flattens an `Option>` to `Option` producing `Some(x)` for `Some(Some(x))` and `None` otherwise. The function is similar to [`Iterator::flatten`].
+
+- [`UdpSocket::peer_addr`]
+
+ Returns the socket address of the remote peer this socket was connected to.
+
+- [`{f32,f64}::to_be_bytes`], [`{f32,f64}::to_le_bytes`],[`{f32,f64}::to_ne_bytes`], [`{f32,f64}::from_be_bytes`], [`{f32,f64}::from_le_bytes`], and [`{f32,f64}::from_ne_bytes`]
+
+ Return the memory representation of the floating point number as a byte array in big-endian (network), little-endian, and native-endian byte order.
+
+### Other changes
+
+[relnotes-cargo]: https://doc.rust-lang.org/nightly/cargo/CHANGELOG.html#cargo-140-2019-12-19
+[relnotes-clippy]: https://github.com/rust-lang/rust-clippy/blob/master/CHANGELOG.md#rust-140
+[compat-notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#compatibility-notes
+
+There are other changes in the Rust 1.40.0 release: check out what changed in [Rust][notes], [Cargo][relnotes-cargo], and [Clippy][relnotes-clippy].
+
+Please also see the [compatibility notes][compat-notes] to check if you're affected by those changes.
+
+## Contributors to 1.40.0
+
+Many people came together to create Rust 1.40.0. We couldn't have done it
+without all of you. [Thanks!](https://thanks.rust-lang.org/rust/1.40.0/)
diff --git a/content/Rust-1.41.0.md b/content/Rust-1.41.0.md
new file mode 100644
index 000000000..5e165d3aa
--- /dev/null
+++ b/content/Rust-1.41.0.md
@@ -0,0 +1,218 @@
++++
+path = "2020/01/30/Rust-1.41.0"
+title = "Announcing Rust 1.41.0"
+authors = ["The Rust Release Team"]
+aliases = [
+ "2020/01/30/Rust-1.41.0.html",
+ "releases/1.41.0",
+]
+
+[extra]
+release = true
++++
+
+The Rust team is happy to announce a new version of Rust, 1.41.0. Rust is a
+programming language that is empowering everyone to build reliable and
+efficient software.
+
+If you have a previous version of Rust installed via rustup, getting Rust
+1.41.0 is as easy as:
+
+```
+$ rustup update stable
+```
+
+If you don't have it already, you can [get `rustup`][install] from the
+appropriate page on our website, and check out the [detailed release notes for
+1.41.0][notes] on GitHub.
+
+[install]: https://www.rust-lang.org/install.html
+[notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1410-2020-01-30
+
+## What's in 1.41.0 stable
+
+The highlights of Rust 1.41.0 include relaxed restrictions for trait
+implementations, improvements to `cargo install`, a more `git`-friendly
+`Cargo.lock`, and new FFI-related guarantees for `Box`. See the [detailed
+release notes][notes] to learn about other changes not covered by this post.
+
+### Relaxed restrictions when implementing traits
+
+[book_orphan]: https://doc.rust-lang.org/book/ch10-02-traits.html#implementing-a-trait-on-a-type
+[ref_orphan]: https://doc.rust-lang.org/reference/items/implementations.html#trait-implementation-coherence
+[book_newtype]: https://doc.rust-lang.org/book/ch19-03-advanced-traits.html#using-the-newtype-pattern-to-implement-external-traits-on-external-types
+[report_orphan]: https://github.com/rust-lang/rust/issues/63599
+[rfc_orphan]: https://rust-lang.github.io/rfcs/2451-re-rebalancing-coherence.html
+
+To prevent breakages in the ecosystem when a dependency adds a new trait
+`impl`, Rust enforces the [*orphan rule*][book_orphan]. The gist of it is that
+a trait `impl` is only allowed if either the trait or the type being
+implemented is *local* to (defined in) the current crate as opposed to a
+*foreign* crate. [What this means exactly][ref_orphan] is complicated, however,
+when generics are involved.
+
+Before Rust 1.41.0, the orphan rule was unnecessarily strict, getting in the
+way of composition. As an example, suppose your crate defines the
+`BetterVec` struct, and you want a way to convert your struct to the
+standard library's `Vec`. The code you would write is:
+
+```rust
+impl From> for Vec {
+ // ...
+}
+```
+
+...which is an instance of the pattern:
+
+```rust
+impl ForeignTrait for ForeignType {
+ // ...
+}
+```
+
+In Rust 1.40.0 this `impl` was forbidden by the orphan rule, as both `From` and
+`Vec` are defined in the standard library, which is foreign to the current
+crate. There were ways to work around the limitation, such as [the *newtype*
+pattern][book_newtype], but they were often cumbersome or even impossible in
+some cases.
+
+While it's still true that both `From` and `Vec` were foreign, the trait (in
+this case `From`) was parameterized by a local type. Therefore, Rust 1.41.0
+allows this `impl`.
+
+For more details, read the [the stabilization report][report_orphan] and [the
+RFC proposing the change][rfc_orphan].
+
+### `cargo install` updates packages when outdated
+
+With `cargo install`, you can install binary crates in your system. The command
+is often used by the community to install popular CLI tools written in Rust.
+
+Starting from Rust 1.41.0, `cargo install` will also update existing
+installations of the crate if a new release came out since you installed it.
+Before this release the only option was to pass the `--force` flag, which
+reinstalls the binary crate even if it's up to date.
+
+### Less conflict-prone `Cargo.lock` format
+
+To ensure consistent builds, Cargo uses a file named `Cargo.lock`, containing
+dependency versions and checksums. Unfortunately, the way the data was arranged
+in it caused unnecessary merge conflicts when changing dependencies in separate
+branches.
+
+Rust 1.41.0 introduces a new format for the file, explicitly designed to avoid
+those conflicts. This new format will be used for all new lockfiles, while
+existing lockfiles will still rely on the previous format. You can learn about
+the choices leading to the new format [in the PR adding it][cargo/7070].
+
+[cargo/7070]: https://github.com/rust-lang/cargo/pull/7070
+
+### More guarantees when using `Box` in FFI
+
+[box_docs]: https://doc.rust-lang.org/std/boxed/index.html
+
+Starting with Rust 1.41.0, we have declared that a `Box`, where `T: Sized`
+is now ABI compatible with the C language's pointer (`T*`) types. So if you
+have an `extern "C"` Rust function, called from C, your Rust function can now
+use `Box`, for some specific `T`, while using `T*` in C for the
+corresponding function. As an example, on the C side you may have:
+
+```c
+// C header
+
+// Returns ownership to the caller.
+struct Foo* foo_new(void);
+
+// Takes ownership from the caller; no-op when invoked with NULL.
+void foo_delete(struct Foo*);
+```
+
+...while on the Rust side, you would have:
+
+```rust
+#[repr(C)]
+pub struct Foo;
+
+#[no_mangle]
+pub extern "C" fn foo_new() -> Box {
+ Box::new(Foo)
+}
+
+// The possibility of NULL is represented with the `Option<_>`.
+#[no_mangle]
+pub extern "C" fn foo_delete(_: Option>) {}
+```
+
+Note however that while `Box` and `T*` have the same representation and ABI,
+a `Box` must still be non-null, aligned, and ready for deallocation by the
+global allocator. To ensure this, it is best to only use `Box`es originating
+from the global allocator.
+
+**Important:** At least at present, you should avoid using `Box` types for
+functions that are defined in C but invoked from Rust. In those cases, you
+should directly mirror the C types as closely as possible. Using types like
+`Box` where the C definition is just using `T*` can lead to undefined
+behavior.
+
+To read more, [consult the documentation for `Box`][box_docs].
+
+### Library changes
+
+[`Result::map_or`]: https://doc.rust-lang.org/std/result/enum.Result.html#method.map_or
+[`Result::map_or_else`]: https://doc.rust-lang.org/std/result/enum.Result.html#method.map_or_else
+[`Option::map_or`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.map_or
+[`Option::map_or_else`]: https://doc.rust-lang.org/std/option/enum.Option.html#method.map_or_else
+[`std::rc::Weak::weak_count`]: https://doc.rust-lang.org/std/rc/struct.Weak.html#method.weak_count
+[`std::rc::Weak::strong_count`]: https://doc.rust-lang.org/std/rc/struct.Weak.html#method.strong_count
+[`std::sync::Weak::weak_count`]: https://doc.rust-lang.org/std/sync/struct.Weak.html#method.weak_count
+[`std::sync::Weak::strong_count`]: https://doc.rust-lang.org/std/sync/struct.Weak.html#method.strong_count
+[pr_66277]: https://github.com/rust-lang/rust/pull/66277
+[pr_65013]: https://github.com/rust-lang/rust/pull/65013
+
+In Rust 1.41.0, we've made the following additions to the standard library:
+
+- The [`Result::map_or`] and [`Result::map_or_else`] methods were stabilized.
+
+ Similar to [`Option::map_or`] and [`Option::map_or_else`], these methods are
+ shorthands for the `.map(|val| process(val)).unwrap_or(default)` pattern.
+
+- [`NonZero*` numerics now implement `From` if it's a smaller integer
+ width.][pr_66277] For example, `NonZeroU16` now implements `From`.
+
+- The `weak_count` and `strong_count` methods on `Weak` pointers were stabilized.
+
+ - [`std::rc::Weak::weak_count`]
+ - [`std::rc::Weak::strong_count`]
+ - [`std::sync::Weak::weak_count`]
+ - [`std::sync::Weak::strong_count`]
+
+ These methods return the number of weak (`rc::Weak` and `sync::Weak`)
+ or strong (`Rc` and `Arc`) pointers to the allocation respectively.
+
+- [`MaybeUninit
+
+*About Nick Cameron: I'm a Rust core team member and lead the dev-tools team. I work on a bunch of
+tools including Rustdoc, Rustfmt, the Rust Language Server, and the Rust compiler. I want to make
+Rust developer tools awesome, and user experience is a key part of that. I want Rust to change the
+world (or at least the programming world), and we can't do that without making the Rust language
+and community more accessible to more people.*
+
+
+
+*About Steve Klabnik: I used to work on Ruby on Rails before Rust, and one of the reasons why I love
+Rust is that as a project, we're committed to helping people learn Rust as their first low-level
+language. So in some sense, I see this as a continuation of that.*
+
+*However, by the same token, many low-level programmers are not web developers. This means that much
+of Rust's web stuff is... not exactly great. Since I come from the web world, I'm trying to help;
+but I'm only one person! And not only that, I'm more of a backend person, and so am personally
+lacking experience with front-end stuff.*
+
+*So, I see this project as a classic skills exchange: you bring your expertise in web technologies,
+we bring our expertise in Rust, everyone learns, and our code gets better!*
+
+### 2. Adding Code Lints to the Clippy Developer Tool
+
+Rust partner: Manish Goregaokar
+
+Clippy is the linter for Rust. It’s a static analysis tool that finds issues in your code and
+reports them to the developer, often with suggested fixes. This project will involve adding more
+such lints and improving the existing ones to be more helpful and user-friendly. We would love your
+ideas and help in the following ways:
+
+1. Improving & fixing bugs in existing Lints.
+2. Adding lints focused on helping people make the transition to Rust from a particular language
+3. Lints that serve as a tutorial that introduce ideas and teach code improvements
+4. Your idea!
+
+Who should apply for this project:
+
+- Some experience using a linter in another language (examples: rubocop in Ruby, jslint in
+ JavaScript, pylint in Python, Coverity, etc)
+- Interest in improving the new Rust developer experience
+- Interest in learning how to improve and create lints
+
+
+
+*About Manish Goregaokar: I'm a research engineer at Mozilla working on Servo. I care a lot about
+improving workflows and tooling, especially around the newcomer experience.*
+
+*I consider open source to be one of the best ways to gain proficiency in programming, and to that
+end I care about making it more accessible and easy to contribute to, both by systemic improvements
+and individual mentorship.*
+
+### 3. Improve the Approachability of the Design of rust-lang.org and/or crates.io
+
+Rust Partner: Aaron Turon
+
+I'd love to pair up with one or more people on the design of [our main
+website](https://www.rust-lang.org/en-US/) and/or [crates.io](https://crates.io/). Both of them
+could *really* be improved in a way that could make a big impact on Rust's approachability, and
+I've got a lot of ideas (and complaints) to start with. There's also potential to bootstrap a whole
+new design subteam from the project, if successful.
+
+This project might choose multiple applicants that would work together as a team.
+
+Who should apply for this project:
+
+- Background in graphic design, web design, information architecture, or user experience
+- Interest in improving approachability of Rust
+- Interest in investigating the motivations behind visitors to the main website and/or crates.io
+
+
+
+*About Aaron Turon: I'm a Rust core team member, manage the Mozilla Rust team, and currently lead
+the library, infrastructure, and Cargo teams. On the technical side, I'm most driven by language
+design and end-to-end user experience. On the people side, I love fostering consensus, building
+teams, and empowering people. I live in Portland, Oregon with my partner and two daughters.*
+
+*Working in an open source community has shown me, over and over, how vital a diversity of
+perspectives and backgrounds can be. My hope is that, by investing in initiatives like this one, we
+can welcome a broader range of people and empower them within the Rust community.*
+
+### 4. Improving the Video Tutorials at intorust.com
+
+Rust partner: Niko Matsakis
+
+[intorust.com](http://intorust.com/) is a website with a collection of screencasts that aim to
+teach key Rust concepts in an easy and accessible way. I would love to work with someone both on
+expanding the material to cover more parts of Rust as well as making sure that it is understandable
+to as broad an audience as possible. Another interesting avenue might be expanding the site to also
+cover background topics like the role of the stack and the heap.
+
+Who should apply for this project:
+
+- Background in teaching or tutoring
+- Background or interest in creating visual teaching tools like diagrams or drawings a plus
+- Interest in learning Rust concepts and teaching what you learn to others
+
+
+
+*About Niko Matsakis: I'm a member of the Rust core team as well as the Rust language and compiler
+teams. I focus mainly on the design and implementation of the language itself. I want to do what I
+can to make learning Rust as smooth as possible for as many people as possible. I think that the
+best way to achieve this goal is to work with people with different backgrounds and experiences,
+since that will affect how they learn the material.*
+
+### 5. Write tutorials for Rocket and Diesel, Parts of Rust’s Web Framework Story
+
+Rust Partner: Sean Griffin
+
+I’m looking for someone with experience in web development in some other web framework to help
+improve the documentation around Rust's frameworks in the web development space. I’d love to
+improve the new user experience for using [Rocket](https://rocket.rs/) (a web framework) and
+[Diesel](http://diesel.rs/) (an ORM) together. This could include writing tutorials, creating
+screencasts, making example applications, or improving the API documentation.
+
+Who should apply for this project:
+
+- Background in teaching or tutoring
+- Experience using a web framework written in some other language
+- Interest in learning how to write web applications in Rust and teaching what you learn to others
+
+
+
+*About Sean Griffin: In addition to my Rust work, I am one of the maintainers of Ruby on Rails. One
+of the great things about Rails (and web development) is that it has really helped to lower the
+barrier to entry. I think Rust can have a similar impact (both for low level programming, and
+competing as a high level language). However, at the moment Rust has a notoriously bad learning
+curve. Improving that with input from as many viewpoints as possible seems like the best way to
+help even the playing field once again.*
+
+### 6. Extending the Literate Programming Tool Tango
+
+Rust partner: Felix Klock
+
+I'm looking for someone interested in ["programs as
+literature"](https://en.wikipedia.org/wiki/Literate_programming) to help me extend
+[`tango`](https://github.com/pnkfelix/tango/) (a literate programming tool for Rust) so that it can
+be used for more than just demos and slideshows. If you have experience writing meta-commentary
+about your own code, documenting how it works for the purpose of teaching others about it, then you
+might be the person I am seeking! Check out [this markdown
+file](https://github.com/pnkfelix/mon-artist/blob/a3388c11e8b1910cc4eb4c31bd1540a46851618b/src/lit/s
+rc/format.md) that tango is able to turn into an executable Rust code file for an example of what
+tango can do. You can see some ideas for extensions from the
+[`tango`](https://github.com/pnkfelix/tango/issues)
+[issues](https://github.com/pnkfelix/tango/issues) page.
+
+Who should apply for this project:
+
+- Background in writing, teaching, or documentation
+- Interest in, and opinions about, improving tools for creating and displaying code documentation
+
+
+
+*About Felix Klock: I'm the main developer of tango (as well as a member of the Rust compiler and
+language teams). I actively use tango for authoring my presentation slides about Rust. I
+hypothesize that literate Rust code can act as advertisement for Rust itself, and would like to
+figure out how we could make the tool more useful for real-world crates.*
+
+*More generally: I am a long adherent to the idea that computers can be a powerful [educational
+tool](http://www.ccs.neu.edu/home/matthias/HtDP2e/part_preface.html). Rust provides a unique vessel
+for the intrepid explorers plunging into and past the levels of abstraction that lie atop the
+machine. I want Rust to maximize its [accessibility to
+all](https://www.mozilla.org/en-US/mission/), so that it does not fall into an echo chamber of
+thought and end up as a technology only usable by elite wizards, thus missing this educational
+opportunity.*
+
+### 7. Finding Missing Pieces in the Crates Ecosystem
+
+Rust partner: Andrew Gallant
+
+I’m interested in working with someone to discover where there might be gaps in the kinds of crates
+that are available. This project would involve first writing a small application in the language or
+framework that you’re most comfortable with. Then we’d attempt to port that application to Rust and
+keep track of where there are libraries missing or functionality missing from the libraries that
+are available. The Rust community can then take your findings to fill in those gaps and make Rust
+usable in more scenarios.
+
+Who should apply for this project:
+
+- Experience using libraries to build applications in some other programming language
+- Interest in learning how to translate an application to Rust
+- Interest in researching and documenting features that libraries have or don’t have
+
+
+
+*About Andrew Gallant: I'm a member of the Rust library team that works with Rust in my free time. I
+am very interested in information retrieval, fast text search and generally improving Rust's
+ecosystem. I'm driven both by own personal interest in technical topics and the desire to teach.
+Aside from my own technical interest in languages like Rust, I really love working on the project
+because it provides an outlet to teach others about the things I've learned. I'm particularly
+interested in improving the learning outcomes for as many people as possible, and would relish the
+opportunity to extend that to folks that I might not have been able to reach otherwise. I live in
+central Massachusetts with my wife.*
+
+### 8. Finding Missing Pieces in the Experience of building a Command Line Interface (CLI) Program
+
+Rust partner: Kamal Marhubi
+
+I find Rust to be a great language for writing small command line tools, but I think it could be
+even better. I'd love to work with someone who wants to write a CLI program, or has one they want
+to port to Rust. There are almost certainly rough edges, and working together would be a great way
+to find them and improve the tooling for everyone.
+
+Who should apply for this project:
+
+- Experience building and using tools with a command line interface in some other language
+- Interest in learning how to write or translate a CLI program to Rust
+- Interest in researching and documenting features that libraries have or don’t have
+
+
+
+*About Kamal Marhubi: I've been writing Rust for about a year and a half. I help maintain nix, a
+library that gives a Rusty interface to unix systems APIs. I've also contributed to rustfmt, rustup,
+and the standard library.*
+
+----
+
+We're excited to get [your application](https://docs.google.com/forms/d/e/1FAIpQLSfbSGuoyZE9dctdEoC_XEZ7j2ox7jQT1zghAOF4iGds2PfBCA/viewform) before July 18! We will notify all applicants by Aug 1.
diff --git a/static/images/2017-06-Increasing-Rusts-Reach/kamalmarhubi.jpeg b/content/Increasing-Rusts-Reach/kamalmarhubi.jpeg
similarity index 100%
rename from static/images/2017-06-Increasing-Rusts-Reach/kamalmarhubi.jpeg
rename to content/Increasing-Rusts-Reach/kamalmarhubi.jpeg
diff --git a/static/images/2017-06-Increasing-Rusts-Reach/manish.png b/content/Increasing-Rusts-Reach/manish.png
similarity index 100%
rename from static/images/2017-06-Increasing-Rusts-Reach/manish.png
rename to content/Increasing-Rusts-Reach/manish.png
diff --git a/static/images/2017-06-Increasing-Rusts-Reach/nmatsakis.jpeg b/content/Increasing-Rusts-Reach/nmatsakis.jpeg
similarity index 100%
rename from static/images/2017-06-Increasing-Rusts-Reach/nmatsakis.jpeg
rename to content/Increasing-Rusts-Reach/nmatsakis.jpeg
diff --git a/static/images/2017-06-Increasing-Rusts-Reach/nrc.jpg b/content/Increasing-Rusts-Reach/nrc.jpg
similarity index 100%
rename from static/images/2017-06-Increasing-Rusts-Reach/nrc.jpg
rename to content/Increasing-Rusts-Reach/nrc.jpg
diff --git a/static/images/2017-06-Increasing-Rusts-Reach/pnkfelix.jpeg b/content/Increasing-Rusts-Reach/pnkfelix.jpeg
similarity index 100%
rename from static/images/2017-06-Increasing-Rusts-Reach/pnkfelix.jpeg
rename to content/Increasing-Rusts-Reach/pnkfelix.jpeg
diff --git a/static/images/2017-06-Increasing-Rusts-Reach/sgrif.jpeg b/content/Increasing-Rusts-Reach/sgrif.jpeg
similarity index 100%
rename from static/images/2017-06-Increasing-Rusts-Reach/sgrif.jpeg
rename to content/Increasing-Rusts-Reach/sgrif.jpeg
diff --git a/static/images/2017-06-Increasing-Rusts-Reach/steveklabnik.jpeg b/content/Increasing-Rusts-Reach/steveklabnik.jpeg
similarity index 100%
rename from static/images/2017-06-Increasing-Rusts-Reach/steveklabnik.jpeg
rename to content/Increasing-Rusts-Reach/steveklabnik.jpeg
diff --git a/content/Increasing-glibc-kernel-requirements.md b/content/Increasing-glibc-kernel-requirements.md
new file mode 100644
index 000000000..6b73c5140
--- /dev/null
+++ b/content/Increasing-glibc-kernel-requirements.md
@@ -0,0 +1,121 @@
++++
+path = "2022/08/01/Increasing-glibc-kernel-requirements"
+title = "Increasing the glibc and Linux kernel requirements"
+authors = ["Nikita Popov"]
+aliases = ["2022/08/01/Increasing-glibc-kernel-requirements.html"]
++++
+
+The minimum requirements for Rust toolchains targeting Linux will [increase][PR] with the
+Rust 1.64.0 release (slated for September 22nd, 2022). The new minimum requirements are:
+
+* glibc >= 2.17 (previously glibc >= 2.11)
+* kernel >= 3.2 (previously kernel >= 2.6.32)
+
+These requirements apply both to running the Rust compiler itself (and other Rust tooling like
+Cargo or Rustup), and to running binaries produced by Rust, if they use the libstd.
+
+If you are not targeting an old long-term-support distribution, or embedded hardware running
+an old Linux version, this change is unlikely to affect you. Otherwise, read on!
+
+# Affected targets
+
+In principle, the new kernel requirements affect all `*-linux-*` targets, while the glibc
+requirements affect all `*-linux-gnu*` targets. In practice, many targets were already requiring
+newer kernel or glibc versions. The requirements for such targets do not change.
+
+Among targets for which a Rust host toolchain is distributed, the following *are* affected:
+
+* `i686-unknown-linux-gnu` (Tier 1)
+* `x86_64-unknown-linux-gnu` (Tier 1)
+* `x86_64-unknown-linux-musl` (Tier 2 with host tools)
+* `powerpc-unknown-linux-gnu` (Tier 2 with host tools)
+* `powerpc64-unknown-linux-gnu` (Tier 2 with host tools)
+* `s390x-unknown-linux-gnu` (Tier 2 with host tools)
+
+The following are *not* affected, because they already had higher glibc/kernel requirements:
+
+* `aarch64-unknown-linux-gnu` (Tier 1)
+* `aarch64-unknown-linux-musl` (Tier 2 with host tools)
+* `arm-unknown-linux-gnueabi` (Tier 2 with host tools)
+* `arm-unknown-linux-gnueabihf` (Tier 2 with host tools)
+* `armv7-unknown-linux-gnueabihf` (Tier 2 with host tools)
+* `mips-unknown-linux-gnueabihf` (Tier 2 with host tools)
+* `powerpc64le-unknown-linux-gnueabihf` (Tier 2 with host tools)
+* `riscv64gc-unknown-linux-gnueabihf` (Tier 2 with host tools)
+
+For other tier 2 or tier 3 targets, for which no Rust toolchain is distributed, we do not
+accurately track minimum requirements, and they may or may not be affected by this change.
+`*-linux-musl*` targets are only affected by the kernel requirements, not the glibc requirements.
+Targets which only use libcore and not libstd are unaffected.
+
+A list of supported targets and their requirements can be found on the
+[platform support page][platform-support].
+
+# Affected systems
+
+The glibc and kernel versions used for the new baseline requirements are already close to a decade
+old. As such, this change should only affect users that either target old long-term-support Linux
+distributions, or embedded hardware running old versions of Linux.
+
+The following Linux distributions *are* still supported under the new requirements:
+
+* RHEL 7 (glibc 2.17, kernel 3.10)
+* SLES 12-SP5 (glibc 2.22, kernel 4.12.14)
+* Debian 8 (glibc 2.19, kernel 3.16.7)
+* Ubuntu 14.04 (glibc 2.19, kernel 3.13)
+
+The following distributions are *not* supported under the new requirements:
+
+* RHEL 6 (glibc 2.12, kernel 2.6.32)
+* SLES 11-SP4 (glibc 2.11.3, kernel 3.0.101)
+* Debian 6 (glibc 2.11, kernel 2.6.32), Debian 7 (glibc 2.13, kernel 3.2.41)
+* Ubuntu 12.04 (glibc 2.15, kernel 3.2)
+
+Out of the distributions in the second list, only RHEL 6 still has limited vendor support (ELS).
+
+# Why increase the requirements?
+
+We want Rust, and binaries produced by Rust, to be as widely usable as possible. At the same time,
+the Rust project only has limited resources to maintain compatibility with old environments.
+
+There are two parts to the toolchain requirements: The minimum requirements for running the Rust
+compiler on a host system, and the minimum requirements for cross-compiled binaries.
+
+The minimum requirements for host toolchains affect our build system. Rust CI produces binary
+artifacts for dozens of different targets. Creating binaries that support old glibc versions
+requires either building on an operating system with old glibc (for native builds) or using a
+buildroot with an old glibc version (for cross-compiled builds).
+
+At the same time, Rust relies on LLVM for optimization and code generation, which regularly
+increases its toolchain requirements. LLVM 16 will require GCC 7.1 or newer (and LLVM 15 supports
+GCC 5.1 in name only). Creating a build environment that has both a very old glibc and a recent
+compiler becomes increasingly hard over time. crosstool-ng (which we use for most cross-compilation
+needs) does not support targeting both glibc 2.11, and using a compiler that satisfies the new LLVM
+requirements.
+
+The requirements for cross-compiled binaries have a different motivation: They affect which kernel
+versions need to be supported by libstd. Increasing the kernel requirements allows libstd to use
+newer syscalls, without having to maintain and test compatibility with kernels that do not support
+them.
+
+The new baseline requirements were picked as the least common denominator among long-term-support
+distributions that still have active support. This is currently RHEL 7 with glibc 2.17 and
+kernel 3.10. The kernel requirement is picked as 3.2 instead, because this is the minimum
+requirement of glibc itself, and there is little relevant API difference between these versions.
+
+# What should I do?
+
+If you or your organization are affected by this change, there are a number of viable options
+depending on your situation:
+
+* Upgrade your target system, or raise the minimum requirements of your software, to satisfy the
+ new constraints.
+* If you are running the Rust compiler on an old host, consider cross-compiling from a newer host
+ instead.
+* If you are targeting an old glibc version, consider targeting musl instead.
+* If you are targeting an old kernel version and use libstd, you may be out of luck: In this case
+ you may have to either freeze your current Rust version, or maintain a fork of libstd that
+ supports older kernels.
+
+[PR]: https://github.com/rust-lang/rust/pull/95026
+[platform-support]: https://doc.rust-lang.org/nightly/rustc/platform-support.html
diff --git a/static/images/2016-04-MIR/cfg.svg b/content/MIR/cfg.svg
similarity index 100%
rename from static/images/2016-04-MIR/cfg.svg
rename to content/MIR/cfg.svg
diff --git a/static/images/2016-04-MIR/drop-unwind.svg b/content/MIR/drop-unwind.svg
similarity index 100%
rename from static/images/2016-04-MIR/drop-unwind.svg
rename to content/MIR/drop-unwind.svg
diff --git a/static/images/2016-04-MIR/drop.svg b/content/MIR/drop.svg
similarity index 100%
rename from static/images/2016-04-MIR/drop.svg
rename to content/MIR/drop.svg
diff --git a/static/images/2016-04-MIR/flow.svg b/content/MIR/flow.svg
similarity index 100%
rename from static/images/2016-04-MIR/flow.svg
rename to content/MIR/flow.svg
diff --git a/content/MIR/index.md b/content/MIR/index.md
new file mode 100644
index 000000000..a80b9d286
--- /dev/null
+++ b/content/MIR/index.md
@@ -0,0 +1,620 @@
++++
+path = "2016/04/19/MIR"
+title = "Introducing MIR"
+authors = ["Niko Matsakis"]
+description = "The shift to use MIR in the compiler should unlock many exciting improvements."
+aliases = ["2016/04/19/MIR.html"]
++++
+
+We are in the final stages of a grand transformation on the Rust
+compiler internals. Over the past year or so, we have been steadily
+working on a plan to change our internal compiler pipeline, as shown
+here:
+
+![Compiler Flowchart][flow]
+
+That is, we are introducing a new intermediate representation (IR) of
+your program that we call **MIR**: MIR stands for *mid-level* IR, because
+the MIR comes between the existing HIR ("high-level IR", roughly an
+[abstract syntax tree][ast]) and [LLVM][llvm] (the "low-level"
+IR). Previously, the "translation" phase in the compiler would convert
+from full-blown Rust into machine-code-like LLVM in one rather large
+step. But now, it will do its work in two phases, with a vastly
+simplified version of Rust -- MIR -- standing in the middle.
+
+If you're not a compiler enthusiast, this all might seem arcane and unlikely to
+affect you directly. But in reality, **MIR is the key to ticking off a number of
+our highest priorities** for Rust:
+
+- **Faster compilation time**. We are working to make Rust's compilation
+ *incremental*, so that when you *re*-compile code, the compiler recomputes only
+ what it has to. MIR has been designed from the start with this use-case in mind,
+ so it's much easier for us to save and reload, even if other parts of the program
+ have changed in the meantime.
+
+ MIR also provides a foundation for more efficient data structures and removal
+ of redundant work in the compiler, both of which should speed up compilation
+ across the board.
+
+- **Faster execution time**. You may have noticed that in the new compiler
+ pipeline, *optimization* appears twice. That's no accident: previously, the
+ compiler relied solely on LLVM to perform optimizations, but with MIR, we can
+ do some *Rust-specific* optimizations before ever hitting LLVM -- or, for that
+ matter, before monomorphizing code. Rust's rich type system should provide
+ fertile ground for going beyond LLVM's optimizations.
+
+ In addition, MIR will uncork some longstanding performance improvements
+ to the code Rust generates, like ["non-zeroing" drop][rfc320].
+
+- **More precise type checking**. Today's Rust compiler imposes some
+ artificial restrictions on *borrowing*, restrictions which largely
+ stem from the way the compiler currently represents programs. MIR
+ will enable [much more flexible borrowing][811], which will in turn
+ improve Rust's ergonomics and learning curve.
+
+Beyond these banner user-facing improvements, **MIR also has substantial
+engineering benefits for the compiler**:
+
+- **Eliminating redundancy.** Currently, because we write all of our passes in
+ terms of the full Rust language, there is quite a lot of duplication. For
+ example, both the safety analyses and the backend which produces LLVM IR must
+ agree about how to translate drops, or the precise order in which `match`
+ expression arms will be tested and executed (which can get quite
+ complex). With MIR, all of that logic is centralized in MIR construction, and
+ the later passes can just rely on that.
+
+- **Raising ambitions.** In addition to being more [DRY][dry], working
+ with MIR is just plain *easier*, because it contains a much more
+ primitive set of operations than ordinary Rust. This simplification
+ enables us to do a lot of things that were forbodingly complex
+ before. We'll look at one such case in this post -- non-zeroing
+ drop -- but as we'll see at the end, there are already many others
+ in the pipeline.
+
+Needless to say, we're excited, and the Rust community has stepped up
+in a big way to make MIR a reality. The compiler can bootstrap and run
+its test suite using MIR, and these tests have to pass on every new
+commit. Once we're able to run [Crater][crater] with MIR enabled and
+see no regressions across the entire [crates.io](https://crates.io/)
+ecosystem, we'll turn it on by default (or, you'll forgive a terrible
+(wonderful) pun, [launch MIR into orbit][orbit]).
+
+This blog post begins with an overview of MIR's design, demonstrating
+some of the ways that MIR is able to abstract away the full details of
+the Rust language. Next, we look at how MIR will help with
+implementing [non-zeroing drops][rfc320], a long-desired
+optimization. If after this post you find you are hungry for more,
+have a look at the [RFC that introduced MIR][rfc1211], or jump right
+into [the code][]. (Compiler buffs may be particularly interested in
+the [alternatives section][alt], which discusses certain design
+choices in detail, such as why MIR does not currently use SSA.)
+
+
+
+### Reducing Rust to a simple core
+
+MIR reduces Rust down to a simple core, removing almost all of the
+Rust syntax that you use every day, such as `for` loops, `match`
+expressions, and even method calls. Instead, those constructs are
+translated to a small set of primitives. This does not mean that MIR
+is a *subset* of Rust. As we'll see, many of these primitives
+operations are not available in real Rust. This is because those
+primitives could be misused to write unsafe or undesirable programs.
+
+The simple core language that MIR supports is not something you would
+want to program in. In fact, it makes things almost painfully
+explicit. But it's great if you want to write a type-checker or
+generate assembly code, as you now only have to handle the core
+operations that remain after MIR translation.
+
+To see what I mean, let's start by simplifying a fragment of Rust code.
+At first, we'll just break the Rust down into "simpler Rust", but
+eventually we'll step away from Rust altogether and into MIR code.
+
+Our Rust example starts out as this simple `for` loop, which iterates
+over all the elements in a vector and processes them one by one:
+
+```rust
+for elem in vec {
+ process(elem);
+}
+```
+
+Rust itself offers three kinds of loops: `for` loops, like this one;
+`while` and `while let` loops, that iterate until some condition is
+met; and finally the simple `loop`, which just iterates until you
+break out of it. Each of these kinds of loops encapsulates a
+particular pattern, so they are quite useful when writing code. But
+for MIR, we'd like to reduce all of these into one core concept.
+
+A `for` loop in Rust works by converting a value into an iterator and
+then repeatedly calling `next` on that iterator. That means that we
+can rewrite the `for` loop we saw before into a `while let` loop
+that looks like this:
+
+```rust
+let mut iterator = vec.into_iter();
+while let Some(elem) = iterator.next() {
+ process(elem);
+}
+```
+
+By applying this rewriting, we can remove all `for` loops, but that
+still leaves multiple kinds of loops. So next we can imagine rewrite
+all `while let` loops into a simple `loop` combined with a `match`:
+
+```rust
+let mut iterator = vec.into_iter();
+loop {
+ match iterator.next() {
+ Some(elem) => process(elem),
+ None => break,
+ }
+}
+```
+
+We've already eliminated two constructs (`for` loops and `while`
+loops), but we can go further still. Let's turn from loops for a bit
+to look at the method calls that we see. In Rust, method calls like
+`vec.into_iter()` and `iterator.next()` are also a kind of
+[syntactic sugar][ss]. These particular methods are defined in traits,
+which are basically pre-defined interfaces. For example, `into_iter`
+is a method in the `IntoIterator` trait. Types which can be converted
+into iterators implement that trait and define how the `into_iter`
+method works for them. Similarly, `next` is defined in the `Iterator`
+trait. When you write a method call like `iterator.next()`, the Rust
+compiler automatically figures out which trait the method belongs to
+based on the type of the `iterator` and the set of traits in
+scope. But if we prefer to be more explicit, we could instead invoke
+the methods in the trait directly, using function call syntax:
+
+```rust
+// Rather than `vec.into_iter()`, we are calling
+// the function `IntoIterator::into_iter`. This is
+// exactly equivalent, just more explicit.
+let mut iterator = IntoIterator::into_iter(vec);
+loop {
+ // Similarly, `iterator.next()` can be rewritten
+ // to make clear which trait the `next` method
+ // comes from. We see here that the `.` notation
+ // was also adding an implicit mutable reference,
+ // which is now made explicit.
+ match Iterator::next(&mut iterator) {
+ Some(elem) => process(elem),
+ None => break,
+ }
+}
+```
+
+At this point, we've managed to reduce the set of language features
+for our little fragment quite a bit: we now only use `loop` loops and
+we don't use method calls. But we could reduce the set of concepts
+further if were moved away from `loop` and `break` and towards
+something more fundamental: `goto`. Using `goto` we could transform
+the previous code example into something like this:
+
+```rust
+ let mut iterator = IntoIterator::into_iter(vec);
+
+loop:
+ match Iterator::next(&mut iterator) {
+ Some(elem) => { process(elem); goto loop; }
+ None => { goto break; }
+ }
+
+break:
+ ...
+```
+
+We've gotten pretty far in breaking our example down into simpler
+constructs. We're not quite done yet, but before we go further it's
+worth stepping back a second to make a few observations:
+
+**Some MIR primitives are more powerful than the structured construct
+they replace.** Introducing the `goto` keyword is a big simplification
+in one sense: it unifies and replaces a large number of control-flow
+keywords. `goto` completely replaces `loop`, `break`, `continue`, but
+it also allows us to simplify `if` and `match` as well (we'll see more
+on `match` in particular in a bit). However, this simplification is
+only possible because `goto` is a *more general* construct than
+`loop`, and it's something we would not want to introduce into the
+language proper, because we don't want people to be able to write
+spaghetti-like-code with complex control-flow that is hard to read and
+follow later. But it's fine to have such a construct in MIR, because
+we know that it will only be used in particular ways, such as to
+express a `loop` or a `break`.
+
+**MIR construction is type-driven.** We saw that all method calls like
+`iterator.next()` can be desugared into fully qualified function calls
+like `Iterator::next(&mut iterator)`. However, doing this rewrite is
+only possible with full type information, since we must (for example)
+know the type of `iterator` to determine which trait the `next` method
+comes from. In general, constructing MIR is only possible after
+type-checking is done.
+
+**MIR makes all types explicit.** Since we are constructing MIR after
+the main type-checking is done, MIR can include full type
+information. This is useful for analyses like the borrow checker,
+which require the types of local variables and so forth to operate,
+but also means we can run the type-checker periodically as a kind of
+sanity check to ensure that the MIR is well-formed.
+
+### Control-flow graphs
+
+In the previous section, I presented a gradual "deconstruction" of a
+Rust program into something resembling MIR, but we stayed in textual
+form. Internally to the compiler, though, we never "parse" MIR or have
+it in textual form. Instead, we represent MIR as a
+[set of data structures][the code] encoding a
+[control-flow graph (CFG)][CFG]. If you've ever used a flow-chart,
+then the concept of a control-flow graph will be pretty familiar to
+you. It's a representation of your program that exposes the underlying
+control flow in a very clear way.
+
+A control-flow graph is structured as a set of basic blocks connected
+by edges. Each basic block contains a sequence of statements and ends
+in a *terminator*, which defines how the blocks are connected to one
+another. When using a control-flow graph, a loop simply appears as a
+cycle in the graph, and the `break` keyword translates into a path out
+of that cycle.
+
+Here is the running example from the previous section, expressed as a
+control-flow graph:
+
+![Control-flow-graph][cfg-img]
+
+Building a control-flow graph is typically a first step for any kind
+of flow-sensitive analysis. It's also a natural match for LLVM IR,
+which is also structured into control-flow graph form. The fact that
+MIR and LLVM correspond to one another fairly closely makes
+translation quite straight-forward. It also eliminates a vector for
+bugs: in today's compiler, the control-flow graph used for analyses is
+not necessarily the same as the one which results from LLVM
+construction, which can lead to incorrect programs being accepted.
+
+### Simplifying match expressions
+
+The example in the previous section showed how we can reduce all of
+Rust's loops into, effectively, gotos in the MIR and how we can remove
+methods calls in favor of calls to explicit calls to trait
+functions. But it glossed over one detail: **match expressions**.
+
+One of the big goals in MIR was to simplify match expressions into a
+very small core of operations. We do this by introducing two
+constructs that the main language does not include: *switches* and
+*variant downcasts*. Like `goto`, these are things that we would not
+want in the base language, because they can be misused to write bad
+code; but they are perfectly fine in MIR.
+
+It's probably easiest to explain match handling by example. Let's
+consider the `match` expression we saw in the previous section:
+
+```rust
+match Iterator::next(&mut iterator) {
+ Some(elem) => process(elem),
+ None => break,
+}
+```
+
+Here, the result of calling `next` is of type `Option
