Adjust feature questions

Author: Mark-Simulacrum

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

@@ -98,7 +98,9 @@ Dependency management is a hard problem, and one of the hardest parts of it is j
 
 For example, let's say you had a dependency called `foo` with features A and B, which was being used by packages `bar` and `baz`, but `bar` depends on `foo+A` and `baz` depends on `foo+B`. Cargo will merge both of those features and compile `foo` as `foo+AB`. This has a benefit that you only have to compile `foo` once, and then it can reused for both `foo` and `bar`.
 
-However, this also comes with a downside. What if `A` and `B` are incompatible? What if your own code is compatible with `foo` but not `foo+A`? A common example of this in the ecosystem is the optional `std` feature included in many `#![no_std]` crates, that allows crates to provide added functionality when `std` is available. Now imagine you want to use the `#![no_std]` version of `foo` in your `#![no_std]` binary, and use the `foo` at build time in your `build.rs`. If your build time dependency depends on `foo+std`, your binary now also depends on `foo+std`, which means it will no longer compile because `std` is not available for your target platform. 
+However, this also comes with a downside. What if a feature enabled in a build-dependency is not compatible with the target you are building for?
+
+A common example of this in the ecosystem is the optional `std` feature included in many `#![no_std]` crates, that allows crates to provide added functionality when `std` is available. Now imagine you want to use the `#![no_std]` version of `foo` in your `#![no_std]` binary, and use the `foo` at build time in your `build.rs`. If your build time dependency depends on `foo+std`, your binary now also depends on `foo+std`, which means it will no longer compile because `std` is not available for your target platform.
 
 This has been a long-standing issue in cargo, and with this release there's a new `resolver` option in your `Cargo.toml`, where you can set `resolver="2"` to tell cargo to try a new approach to resolving features. You can check out [RFC 2957] for a detailed description of the behaviour, which can be summarised as follows.