Rust 1.36 release tweaks

posts/2019-07-04-Rust-1.36.0.md

@@ -50,8 +50,8 @@ 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<T>`,
 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.
+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`.
@@ -82,7 +82,7 @@ However, [`mem::uninitialized`] is an incredibly dangerous operation that essent
 cannot be used correctly as the Rust compiler assumes that values are properly initialized.
 For example, calling `mem::uninitialized::<bool>()` 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`.
+nor `1` (for `true`) - the only two allowed bit patterns for `bool`.
 
 To remedy this situation, in Rust 1.36.0, the type [`MaybeUninit<T>`] has been [stabilized][pr-60445].
 The Rust compiler will understand that it should not assume that a [`MaybeUninit<T>`] is a properly initialized `T`.