Fix hidelines syntax change.

Author: willcrichton

src/ch04-02-references-and-borrowing.md

@@ -75,7 +75,7 @@ References are **non-owning pointers**, because they do not own the data they po
 The previous examples using boxes and strings have not shown how Rust "follows" a pointer to its data. For example, the `println!` macro has mysteriously worked for both owned strings of type `String`, and for string references of type `&String`. The underlying mechanism is the **dereference** operator, written with an asterisk (`*`). For example, here's a program that uses dereferences in a few different ways:
 
 ```aquascope,interpreter
-#fn main() {
+# fn main() {
 let mut x: Box<i32> = Box::new(1);
 let a: i32 = *x;         // *x reads the heap value, so a = 1
 *x += 1;                 // *x on the left-side modifies the heap value,
@@ -86,15 +86,15 @@ let b: i32 = **r1;       // two dereferences get us to the heap value
 
 let r2: &i32 = &*x;      // r2 points to the heap value directly
 let c: i32 = *r2;`[]`    // so only one dereference is needed to read it
-#}
+# }
 ```
 
 Observe the difference between `r1` pointing to `x` on the stack, and `r2` pointing to the heap value `2`.
 
 You probably won't see the dereference operator very often when you read Rust code. Rust implicitly inserts dereferences and references in certain cases, such as calling a method with the dot operator. For example, this program shows two equivalent ways of calling the [`i32::abs`](https://doc.rust-lang.org/std/primitive.i32.html#method.abs) (absolute value) and [`str::len`](https://doc.rust-lang.org/std/primitive.str.html#method.len) (string length) functions:
 
 ```rust,ignore
-#fn main()  {
+# fn main()  {
 let x: Box<i32> = Box::new(-1);
 let x_abs1 = i32::abs(*x); // explicit dereference
 let x_abs2 = x.abs();      // implicit dereference
@@ -109,7 +109,7 @@ let s = String::from("Hello");
 let s_len1 = str::len(&s); // explicit reference
 let s_len2 = s.len();      // implicit reference
 assert_eq!(s_len1, s_len2);
-#}
+# }
 ```
 
 This example shows implicit conversions in three ways:

src/ch04-03-fixing-ownership-errors.md

@@ -284,34 +284,34 @@ In sum, **if a value does not own heap data, then it can be copied without a mov
 So if we have a vector of non-`Copy` types like `String`, then how do we safely get access to an element of the vector? Here's a few different ways to safely do so. First, you can avoid taking ownership of the string and just use an immutable reference:
 
 ```rust,ignore
-#fn main() {
+# fn main() {
 let v: Vec<String> = vec![String::from("Hello world")];
 let s_ref: &String = &v[0];
 println!("{s_ref}!");
-#}
+# }
 ```
 
 Second, you can clone the data if you want to get ownership of the string while leaving the vector alone:
 
 ```rust,ignore
-#fn main() {
+# fn main() {
 let v: Vec<String> = vec![String::from("Hello world")];
 let mut s: String = v[0].clone();
 s.push('!');
 println!("{s}");
-#}
+# }
 ```
 
 Finally, you can use a method like [`Vec::remove`] to move the string out of the vector:
 
 ```rust,ignore
-#fn main() {
+# fn main() {
 let mut v: Vec<String> = vec![String::from("Hello world")];
 let mut s: String = v.remove(0);
 s.push('!');
 println!("{s}");
 assert!(v.len() == 0);
-#}
+# }
 ```
 
 
@@ -424,24 +424,24 @@ error[E0502]: cannot borrow `a[_]` as immutable because it is also borrowed as m
 Again, **this program is safe.** For cases like these, Rust often provides a function in the standard library that can work around the borrow checker. For example, we could use [`slice::split_at_mut`][split_at_mut]:
 
 ```rust,ignore
-#fn main() {
+# fn main() {
 let mut a = [0, 1, 2, 3];
 let (a_l, a_r) = a.split_at_mut(2);
 let x = &mut a_l[1];
 let y = &a_r[0];
 *x += *y;
-#}
+# }
 ```
 
 You might wonder, but how is `split_at_mut` implemented? In some Rust libraries, especially core types like `Vec` or `slice`, you will often find **`unsafe` blocks**. `unsafe` blocks allow the use of "raw" pointers, which are not checked for safety by the borrow checker. For example, we could use an unsafe block to accomplish our task:
 
 ```rust,ignore
-#fn main() {
+# fn main() {
 let mut a = [0, 1, 2, 3];
 let x = &mut a[1] as *mut i32;
 let y = &a[2] as *const i32;
 unsafe { *x += *y; } // DO NOT DO THIS unless you know what you're doing!
-#}
+# }
 ```
 
 Unsafe code is sometimes necessary to work around the limitations of the borrow checker. As a general strategy, let's say the borrow checker rejects a program you think is actually safe. Then you should look for standard library functions (like `split_at_mut`) that contain `unsafe` blocks which solve your problem. We will discuss unsafe code further in [Chapter 20][unsafe]. For now, just be aware that unsafe code is how Rust implements certain otherwise-impossible patterns.

src/ch18-02-trait-objects.md

@@ -231,19 +231,19 @@ Rust just needs to know the type of a single element in the vector to infer `T`.
 an empty vector causes a type inference error:
 
 ```rust,ignore,does_not_compile
-#fn main() {
+# fn main() {
 let v = vec![];
 // error[E0282]: type annotations needed for `Vec<T>`
-#}
+# }
 ```
 
 But adding an element enables Rust to infer the type of the vector:
 
 ```rust,ignore
-#fn main() {
+# fn main() {
 let v = vec!["Hello world"];
 // ok, v : Vec<&str>
-#}
+# }
 ```
 
 Type inference is trickier for trait objects. For example, say we tried to factor