Update text to mention 2024 edition.

src/cargo/rust-ecosystem.md

@@ -32,8 +32,8 @@ Key points:
 - Dependencies can also be resolved from alternative [registries], git, folders,
   and more.
 
-- Rust also has [editions]: the current edition is Rust 2021. Previous editions
-  were Rust 2015 and Rust 2018.
+- Rust also has [editions]: the current edition is Rust 2024. Previous editions
+  were Rust 2015, Rust 2018 and Rust 2021.
 
   - The editions are allowed to make backwards incompatible changes to the
     language.

src/unsafe-rust/mutable-static.md

@@ -22,6 +22,7 @@ static mut COUNTER: u32 = 0;
 
 fn add_to_counter(inc: u32) {
     // SAFETY: There are no other threads which could be accessing `COUNTER`.
+    #[allow(static_mut_refs)]
     unsafe {
         COUNTER += inc;
     }
@@ -31,6 +32,7 @@ fn main() {
     add_to_counter(42);
 
     // SAFETY: There are no other threads which could be accessing `COUNTER`.
+    #[allow(static_mut_refs)]
     unsafe {
         println!("COUNTER: {COUNTER}");
     }
@@ -40,12 +42,16 @@ fn main() {
 <details>
 
 - The program here is safe because it is single-threaded. However, the Rust
-  compiler is conservative and will assume the worst. Try removing the `unsafe`
-  and see how the compiler explains that it is undefined behavior to mutate a
-  static from multiple threads.
-
-- Using a mutable static is generally a bad idea, but there are some cases where
-  it might make sense in low-level `no_std` code, such as implementing a heap
-  allocator or working with some C APIs.
+  compiler reasons about functions individually so can't assume that. Try
+  removing the `unsafe` and see how the compiler explains that it is undefined
+  behavior to access a mutable static from multiple threads.
+- Rust 2024 edition goes further and makes accessing a mutable static by
+  reference an error by default. We work around this in the example with
+  `#[allow(static_mut_refs)]`. Don't do this.
+- Using a mutable static is almost always a bad idea, you should use interior
+  mutability instead.
+- There are some cases where it might be necessary in low-level `no_std` code,
+  such as implementing a heap allocator or working with some C APIs. In this
+  case you should use pointers rather than references.
 
 </details>

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

@@ -11,9 +11,13 @@ preconditions to avoid undefined behaviour.
 /// The pointers must be valid, properly aligned, and not otherwise accessed for
 /// the duration of the function call.
 unsafe fn swap(a: *mut u8, b: *mut u8) {
-    let temp = *a;
-    *a = *b;
-    *b = temp;
+    // SAFETY: Our caller promised that the pointers are valid, properly aligned
+    // and have no other access.
+    unsafe {
+        let temp = *a;
+        *a = *b;
+        *b = temp;
+    }
 }
 
 fn main() {
@@ -35,9 +39,9 @@ fn main() {
 We wouldn't actually use pointers for a `swap` function --- it can be done
 safely with references.
 
-Note that unsafe code is allowed within an unsafe function without an `unsafe`
-block. We can prohibit this with `#[deny(unsafe_op_in_unsafe_fn)]`. Try adding
-it and see what happens. This will
-[change in the 2024 Rust edition](https://github.com/rust-lang/rust/issues/120535).
+Note that Rust 2021 and earlier allow unsafe code within an unsafe function
+without an `unsafe` block. This changed in the 2024 edition. We can prohibit it
+in older editions with `#[deny(unsafe_op_in_unsafe_fn)]`. Try adding it and see
+what happens.
 
 </details>