Merge pull request #374 from t-webber/master

fix grammar errors

Author: traviscross

src/rust-2024/cargo-inherited-default-features.md

@@ -38,7 +38,7 @@ Just beware that if you build multiple workspace members at the same time, the f
 
 When using `cargo fix --edition`, Cargo will automatically update your `Cargo.toml` file to remove `default-features = false` in this situation.
 
-If you would prefer to update your `Cargo.toml` manually, check for any warnings when running a build and remove the corresponding entries.
+If you prefer to update your `Cargo.toml` manually, check for any warnings when running a build and remove the corresponding entries.
 Previous editions should display something like:
 
 ```text

src/rust-2024/cargo-resolver.md

@@ -17,7 +17,7 @@ which will imply [`resolver.incompatible-rust-version = "fallback"`].
 The resolver is a global setting for a [workspace], and the setting is ignored in dependencies.
 The setting is only honored for the top-level package of the workspace.
 If you are using a [virtual workspace], you will still need to explicitly set the [`resolver` field]
-in the `[workspace]` definition if you want to opt-in to the new resolver.
+in the `[workspace]` definition if you want to opt in to the new resolver.
 
 For more details on how Rust-version aware dependency resolution works, see [the Cargo book](../../cargo/reference/resolver.html#rust-version).
 

src/rust-2024/cargo-table-key-names.md

@@ -38,4 +38,4 @@ Notice that the underscores were changed to dashes for `dev_dependencies` and `d
 
 When using `cargo fix --edition`, Cargo will automatically update your `Cargo.toml` file to use the preferred table and key names.
 
-If you would prefer to update your `Cargo.toml` manually, be sure to go through the list above and make sure only the new forms are used.
+If you prefer to update your `Cargo.toml` manually, be sure to go through the list above and make sure only the new forms are used.

src/rust-2024/newly-unsafe-functions.md

@@ -18,7 +18,7 @@ Over time it has become evident that certain functions in the standard library s
 
 ### `std::env::{set_var, remove_var}`
 
-It can be unsound to call [`std::env::set_var`] or [`std::env::remove_var`] in a multi-threaded program due to safety limitations of the way the process environment is handled on some platforms. The standard library originally defined these as safe functions, but it was later determined that was not correct.
+It can be unsound to call [`std::env::set_var`] or [`std::env::remove_var`] in a multithreaded program due to safety limitations of the way the process environment is handled on some platforms. The standard library originally defined these as safe functions, but it was later determined that was not correct.
 
 It is important to ensure that these functions are not called when any other thread might be running. See the [Safety] section of the function documentation for more details.
 

src/rust-2024/rpit-lifetime-capture.md

@@ -252,7 +252,7 @@ fn f<'a, T: 'a>(x: &'a (), y: T) -> impl Sized + 'a {
 }
 ```
 
-This trick was less baroque than the `Captures` trick, but also less correct.  As we can see in the example above, even though any lifetime components within `T` are independent from the lifetime `'a`, we're required to add a `T: 'a` bound in order to make the trick work.  This created undue and surprising restrictions on callers.
+This trick was less baroque than the `Captures` trick, but also less correct.  As we can see in the example above, even though any lifetime components within `T` are independent of the lifetime `'a`, we're required to add a `T: 'a` bound in order to make the trick work.  This created undue and surprising restrictions on callers.
 
 Using precise capturing, you can write the above instead, in all editions, as:
 

src/rust-2024/temporary-tail-expr-scope.md

@@ -55,7 +55,7 @@ In 2021 the local variable `c` is dropped before the temporary created by `c.bor
 
 ### Temporary scope may be narrowed
 
-When a temporary is created in order to evaluate an expression, the temporary is dropped based on the [temporary scope rules]. Those rules define how long the temporary will be kept alive. Before 2024, temporaries from tail expressions of a block would be extended outside of the block to the next temporary scope boundary. In many cases this would be the end of a statement or function body. In 2024, the temporaries of the tail expression may now be dropped immediately at the end of the block (before any local variables in the block).
+When a temporary is created in order to evaluate an expression, the temporary is dropped based on the [temporary scope rules]. Those rules define how long the temporary will be kept alive. Before 2024, temporaries from tail expressions of a block would be extended outside the block to the next temporary scope boundary. In many cases this would be the end of a statement or function body. In 2024, the temporaries of the tail expression may now be dropped immediately at the end of the block (before any local variables in the block).
 
 This narrowing of the temporary scope may cause programs to fail to compile in 2024. For example: