Typo fixes

src/d_pattern_matching.rs

@@ -1,5 +1,5 @@
 //! Complete the following functions using the pattern matching syntax. That includes the `match`
-//! statement of the `matches!()` macro, if you feel like having an "1-liner".
+//! statement or the `matches!()` macro, if you feel like having an "1-liner".
 //!
 //! You can try and write them imperatively at first as well, but at the end of the day, we want you
 //! to write them using the `match` keyword or the `matches!` macro.

src/e_common_traits.rs

@@ -18,7 +18,7 @@ pub struct Employee {
 	pub uid: u32,
 }
 
-// We want to consider two employee instances equal iff they have the same `uid`.
+// We want to consider two employee instances equal if they have the same `uid`.
 
 impl PartialEq for Employee {
 	fn eq(&self, other: &Self) -> bool {

src/h_advanced_traits.rs

@@ -187,7 +187,7 @@ impl<F1: Fuel, F2: Fuel> Fuel for Mixed<F1, F2> {
 }
 
 // Now think about how you can make the mixer configurable, such that it would produce a new fuel
-// with an energy density that is more influences by one type than the other.
+// with an energy density that is more influenced by one type than the other.
 //
 // For example, you have a mixer of F1, F2, and some coefficient C1, where the energy density of the
 // mixture is `F1 * C1 + F2 * (1 - C1) )` where `C1` is a ratio (which you have to represent again
@@ -215,7 +215,7 @@ pub fn omni_80_energy(amount: u32) -> BTU {
 
 // Finally, let's consider marker traits, and some trait bounds.
 
-/// Some traits are just markers. They don't bring any additional functionality anything, other than
+/// Some traits are just markers. They don't bring any additional functionality, other than
 /// marking a type with some trait.
 pub trait IsRenewable {}
 impl IsRenewable for LithiumBattery {}

src/m_builder.rs

@@ -14,7 +14,7 @@ use crate::e_common_traits::Employee;
 /// where the `name` and `uid` must be initialized, but the `experience` and `wage` can be left at
 /// their default values, 0.
 ///
-/// The final `fn build` return `Err(())` if either of `name` or `id` are not specified. See the
+/// The final `fn build` should return `Err(())` if either of `name` or `uid` are not specified. See the
 /// example section below.
 ///
 /// > PS. Did you now know that the code snippets in your rust docs also compile, and are tested?
@@ -104,13 +104,13 @@ pub struct UnIdentified;
 /// A new builder that uses the "type-state" pattern to ensure that the user has set the name and
 /// uid. The main trick here is that instead of having `name` be represented by `Option<String>`, we
 /// have two unique types mimicking the `Option<_>`: `Named { .. }` is analogous to `Some(_)` and
-/// `UnNamed` is analogous to `None`. But, `Option<_>` is jus ONE type, but `Named` and `UnNamed`
+/// `UnNamed` is analogous to `None`. But, `Option<_>` is just ONE type, but `Named` and `UnNamed`
 /// are two different types.
 ///
 /// What's the benefit of that? we can make sure that the `fn build` is only implemented if both the
 /// `Name` and `Id` generics are set to `Named` and `Identified`.
 ///
-/// > Did you know that not only you can write tests in your rust-docs, as we did in
+/// > Did you know that not only can you write tests in your rust-docs, as we did in
 /// > [`EmployeeBuilder`], you can also write snippets of code that MUST FAIL TO COMPILE? Cool, eh?
 /// > See: <https://doc.rust-lang.org/rustdoc/write-documentation/documentation-tests.html>
 ///