diff --git a/posts/inside-rust/2023-09-25-polonius-update.md b/posts/inside-rust/2023-09-25-polonius-update.md
index 5ba26fc4a..f15467ef6 100644
--- a/posts/inside-rust/2023-09-25-polonius-update.md
+++ b/posts/inside-rust/2023-09-25-polonius-update.md
@@ -29,7 +29,7 @@ fn get_default<'r, K: Hash + Eq + Copy, V: Default>(
 }                                          // v
 ```
 
-Returning the mutable reference `value` in the `Some` path requires the mutable loan on `map` to live until the end of the function. This prevents mutation in the `None` path even though no mutable loan on `map` would exist there in the first place. 
+Returning the mutable reference `value` in the `Some` path requires the mutable loan on `map` to live until the end of the function. This prevents mutation in the `None` path even though no mutable loan on `map` would exist there in the first place.
 
 Fixing this borrowck issue requires more precision about flow-sensitivity. It also hints at limitations in our modeling of lifetimes, which appear more clearly in cases with only slightly more complicated control flow, like [issue #47680](https://github.com/rust-lang/rust/issues/47680):
 
@@ -88,7 +88,7 @@ Current status: ⏳ members of the types team are starting to work on this task
 
 Out of the two key differences between Polonius and the existing borrow check (regions as "sets of loans", and computing subtyping relations at each point in the CFG), this step is aimed at resolving the *first* difference, but not the second, so we call it the "location *in*sensitive loans in scope" (because subtyping is being done once, not per location): the idea can be described as "NLLs with the Polonius model".
 
-Note that other aspects of the existing borrow checker are still flow-sensitive. 
+Note that other aspects of the existing borrow checker are still flow-sensitive.
 
 In this step, we will compute the set of live loans via outlives constraints only, instead of computing the CFG points where regions are live (which is then used to compute when loans go out of scope). We believe this is equivalent to the existing borrow check in terms of the errors that get reported.
 
@@ -108,11 +108,11 @@ Current status: ⏳ in-progress, the crater run itself will be done before the P
 ### 4. Replace parts of the borrow checker with location-insensitive Polonius
 
 
-The prototype only does additional work, and does not modify the existing analysis. 
+The prototype only does additional work, and does not modify the existing analysis.
 
-In this step, we will refactor the borrow checker so that its data structures store sets of loans, and do more performance work: for example, remove redundant computation, investigate worst-case scalability and constant factors. 
+In this step, we will refactor the borrow checker so that its data structures store sets of loans, and do more performance work: for example, remove redundant computation, investigate worst-case scalability and constant factors.
 
-It's expected that performance will be similar, and we can then imagine enabling the location-insensitive pass without the feature flag, and removing some of the old code. 
+It's expected that performance will be similar, and we can then imagine enabling the location-insensitive pass without the feature flag, and removing some of the old code.
 
 To keep the high quality diagnostics from the years of work of many contributors, it's possible that the new analysis could run, and if errors are detected, only then use the existing analysis and diagnostics.
 
@@ -136,7 +136,7 @@ Interestingly, this work is completely independent of rustc, and could in theory
 
 ### 7. Location-sensitive pass stable
 
-In this milestone, we expect a lot of work on optimizations, and productization. 
+In this milestone, we expect a lot of work on optimizations, and productization.
 
 If a similar experience to NLLs in edition 2018 is to be expected again, another substantial amount of work and polish will also be needed to handle diagnostic differences and issues, ensuring errors and notes are clear enough, as well as the documentation.