diff --git a/src/borrow_check/region_inference/member_constraints.md b/src/borrow_check/region_inference/member_constraints.md
index 9e22aabc9..dfc4327e5 100644
--- a/src/borrow_check/region_inference/member_constraints.md
+++ b/src/borrow_check/region_inference/member_constraints.md
@@ -141,7 +141,7 @@ i.e., that `'0` must be *smaller* than. In our example, this would be
 examples, the chain may be more indirect.
 
 We can use upper bounds to rule out members in a very similar way to
-lower lower bounds. If UB is some upper bound, then we know that `UB:
+lower bounds. If UB is some upper bound, then we know that `UB:
 '0` must hold, so we can rule out any choice `'choice` where `UB:
 'choice` does not hold.
 
diff --git a/src/borrow_check/region_inference/placeholders_and_universes.md b/src/borrow_check/region_inference/placeholders_and_universes.md
index e1c28ba4c..967aa0d33 100644
--- a/src/borrow_check/region_inference/placeholders_and_universes.md
+++ b/src/borrow_check/region_inference/placeholders_and_universes.md
@@ -75,7 +75,7 @@ index**. The idea of a "universe" is that it is a set of names that
 are in scope within some type or at some point. Universes are formed
 into a tree, where each child extends its parents with some new names.
 So the **root universe** conceptually contains global names, such as
-the the lifetime `'static` or the type `i32`. In the compiler, we also
+the lifetime `'static` or the type `i32`. In the compiler, we also
 put generic type parameters into this root universe (in this sense,
 there is not just one root universe, but one per item). So consider
 this function `bar`:
diff --git a/src/mir/dataflow.md b/src/mir/dataflow.md
index 9958f19b9..61277846b 100644
--- a/src/mir/dataflow.md
+++ b/src/mir/dataflow.md
@@ -147,7 +147,7 @@ when possible.
 
 Calling `iterate_to_fixpoint` on your `Engine` will return a `Results`, which
 contains the dataflow state at fixpoint upon entry of each block. Once you have
-a `Results`, you can can inspect the dataflow state at fixpoint at any point in
+a `Results`, you can inspect the dataflow state at fixpoint at any point in
 the CFG. If you only need the state at a few locations (e.g., each `Drop`
 terminator) use a [`ResultsCursor`]. If you need the state at *every* location,
 a [`ResultsVisitor`] will be more efficient.
diff --git a/src/param_env.md b/src/param_env.md
index 9050c5c79..08e19c339 100644
--- a/src/param_env.md
+++ b/src/param_env.md
@@ -1,6 +1,6 @@
 # Parameter Environment
 
-When working with associated and/or or generic items (types, constants,
+When working with associated and/or generic items (types, constants,
 functions/methods) it is often relevant to have more information about the
 `Self` or generic parameters. Trait bounds and similar information is encoded in
 the [`ParamEnv`][pe]. Often this is not enough information to obtain things like the