Apply suggestions from code review

Co-authored-by: Mark Rousskov <mark.simulacrum@gmail.com>

Author: XAMPPRocky

posts/2021-03-25-Rust-1.51.0.md

@@ -24,11 +24,11 @@ from the appropriate page on our website, and check out the
 [notes]: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1510-2021-03-25
 
 ## What's in 1.51.0 stable
-This release represents one of the largest additions to the Rust language and cargo in quite a while. With the stabilization of const generics, and the new feature resolver, along with more minor additions such as the `split-debuginfo` option, and the `addr_of!` API. Let's dive right into it!
+This release represents one of the largest additions to the Rust language and Cargo in quite a while, stabilizing an MVP of const generics and a new feature resolver for Cargo. Let's dive right into it!
 
 
 ### Const Generics MVP
-Before this release, Rust allowed you to haves your types be parameterized over lifetimes or types. For example if we wanted to have a `struct` that is generic over an array of 32 items, we'd write the following:
+Before this release, Rust allowed you to haves your types be parameterized over lifetimes or types. For example if we wanted to have a `struct` that is generic over the element type of an array, we'd write the following:
 
 ```rust
 struct FixedArray<T> {
@@ -46,7 +46,7 @@ struct FixedArray<u8> {
 }
 ```
 
-This is a powerful feature that allows you to write reusable code with no runtime overhead. Enabling to have types that fit a wide variety of use-cases and types. However, until this release it hasn't been possible to easily be generic over the *values* of those types. This was most notable in arrays where they include their length in their type definition (`[T; N]`). Now with 1.51.0 you can write code that is generic over the values of any integer, `bool`, or `char` type! (Using `struct` or `enum` values is still unstable.)
+This is a powerful feature that allows you to write reusable code with no runtime overhead. However, until this release it hasn't been possible to easily be generic over the *values* of those types. This was most notable in arrays which include their length in their type definition (`[T; N]`), which previously you could not be generic over. Now with 1.51.0 you can write code that is generic over the values of any integer, `bool`, or `char` type! (Using `struct` or `enum` values is still unstable.)
 
 This change now lets us have our own array struct that's generic over its type *and* its length. Let's look at an example definition, and how it can be used.
 
@@ -129,11 +129,11 @@ resolver = "2"
 [feature-resolver@2.0]: https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2
 
 ### Splitting Debug Information
-While not often highlighted in the release, the Rust teams are constantly working on improving Rust's compile times, and this release marks one of the biggest improvements in a long time for Rust on macOS platforms. Debug information is code that maps the binary code back to your source code, so that the program can give you more information about what went wrong at run time. In macOS this is done with a tool called `dsymutil` which collects all the debug information into a single `.dSYM` folder.
+While not often highlighted in the release, the Rust teams are constantly working on improving Rust's compile times, and this release marks one of the largest improvements in a long time for Rust on macOS platforms. Debug information is code that maps the binary code back to your source code, so that the program can give you more information about what went wrong at runtime. In macOS, debug info is typically collected using a tool called `dsymutil` which places all the debug information into a single `.dSYM` folder.
 
-This tool provides a lot of benefits, however, one of the drawbacks has been that `dsymutil` is not really compatible with incremental recompilation. This means that even when you make a small change such as a function name, `dsymutil` will need to run over the entire final binary to produce the final `.dSYM` folder. This can sometimes add a lot to the build time, (especially for larger projects), but this has been a necessary step as without it Rust wouldn't be able to parse debug info on macOS.
+This tool provides a lot of benefits, however, one of the drawbacks has been that `dsymutil` is not really compatible with incremental recompilation. This means that even when you make a small change such as a function name, `dsymutil` will need to run over the entire final binary to produce the final `.dSYM` folder. This can sometimes add a lot to the build time, especially for larger projects, as each dependency needs to be recollected, but this has been a necessary step as without it Rust wouldn't be able to load the debug info on macOS.
 
-With the implementation of the Rust-based `backtrace` crate backend, we can now parse debuginfo even without running `dsymutil`. This can significantly speed up builds that include debuginfo and significantly reduce the amount of disk space used. We haven't run extensive benchmarks but have seen a lot of anecdata of people's builds building a lot faster on macOS with this behaviour.
+Recently, Rust backtraces switched to using a different backend which supports loading debuginfo without needing to run `dsymutil`. This can significantly speed up builds that include debuginfo and significantly reduce the amount of disk space used. We haven't run extensive benchmarks but have seen a lot of reports of people's builds being a lot faster on macOS with this behavior.
 
 You can enable this new behaviour by setting the `-Csplit-debuginfo=unpacked` flag when running `rustc`, or by setting the [`split-debuginfo`] `[profile]` option to `unpacked` in Cargo. The "unpacked" option instructs rustc to leave the .o object files in the build output directory instead of deleting them, and skips the step of running dsymutil. Rust's backtrace support is smart enough to know how to find these .o files. Tools such as lldb also know how to do this. This should work as long as you don't need to move the binary to a different location while retaining the debug information.
 
@@ -146,7 +146,7 @@ split-debuginfo = "unpacked"
 
 ### Stabilized APIs
 
-In total, this release saw the stabilisation of 18 new methods for various types like `slice` and `Peekable`. One notable addition is the stabilisation of `ptr::addr_of!` and `ptr::addr_of_mut!`, which allow you to create unaligned references to data. Previously this wasn't possible because Rust requires `&/&mut` to be aligned and point to initialized data, and `&addr as *const _` would cause undefined behaviour as `&addr` needs to be aligned. These two macros now let you safely create unaligned references.
+In total, this release saw the stabilisation of 18 new methods for various types like `slice` and `Peekable`. One notable addition is the stabilisation of `ptr::addr_of!` and `ptr::addr_of_mut!`, which allow you to create raw pointers to unaligned fields. Previously this wasn't possible because Rust requires `&/&mut` to be aligned and point to initialized data, and `&addr as *const _` would then cause undefined behaviour as `&addr` needs to be aligned. These two macros now let you safely create unaligned pointers.
 
 ```rust
 use std::ptr;
@@ -189,8 +189,8 @@ The following methods were stabilised.
 [`panic::panic_any`]: https://doc.rust-lang.org/stable/std/panic/fn.panic_any.html
 [`slice::strip_prefix`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.strip_prefix
 [`slice::strip_suffix`]: https://doc.rust-lang.org/stable/std/primitive.slice.html#method.strip_prefix
-[`Arc::increment_strong_count`]: https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.increment_strong_count
-[`Arc::decrement_strong_count`]: https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.decrement_strong_count
+[`Arc::increment_strong_count`]: https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#method.increment_strong_count
+[`Arc::decrement_strong_count`]: https://doc.rust-lang.org/stable/std/sync/struct.Arc.html#method.decrement_strong_count
 [`slice::fill_with`]: https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.fill_with
 [`ptr::addr_of!`]: https://doc.rust-lang.org/nightly/std/ptr/macro.addr_of.html
 [`ptr::addr_of_mut!`]: https://doc.rust-lang.org/nightly/std/ptr/macro.addr_of_mut.html