try to fixup code examples

src/rust-2024/never-type-fallback.md

@@ -11,7 +11,7 @@
 When the compiler sees a value of type ! in a [coercion site],
 it implicitly inserts a coercion to allow the type checker to infer any type:
 
-```rust
+```rust,ignore (has placeholders)
 // this
 let x: u8 = panic!();
 
@@ -25,7 +25,7 @@ fn absurd<T>(_: !) -> T { ... }
 
 This can lead to compilation errors if the type cannot be inferred:
 
-```rust
+```rust,ignore (uses code from previous example)
 // this
 { panic!() };
 
@@ -36,7 +36,7 @@ This can lead to compilation errors if the type cannot be inferred:
 To prevent such errors, the compiler remembers where it inserted absurd calls,
 and if it can’t infer the type, it uses the fallback type instead:
 
-```rust
+```rust,ignore (has placeholders, uses code from previous example)
 type Fallback = /* An arbitrarily selected type! */;
 { absurd::<Fallback>(panic!()) }
 ```
@@ -67,7 +67,7 @@ The complication is that it might not be trivial to see which type needs to be s
 One of the most common patterns which are broken by this change is using `f()?;` where `f` is
 generic over the ok-part of the return type:
 
-```rust
+```rust,ignore (can't compile outside of a result-returning function)
 fn f<T: Default>() -> Result<T, ()> {
     Ok(T::default())
 }
@@ -80,19 +80,19 @@ desugaring of `?` operator it used to be inferred to `()`, but it will be inferr
 
 To fix the issue you need to specify the `T` type explicitly:
 
-```rust
+```rust,ignore (can't compile outside of a result-returning function, mentions function from previous example)
 f::<()>()?;
 // OR
 () = f()?;
 ```
 
 Another relatively common case is `panic`king in a closure:
 
-```rust
+```rust,edition2015
 trait Unit {}
 impl Unit for () {}
 
-fn run(f: impl FnOnce() -> impl Unit) {
+fn run<R: Unit>(f: impl FnOnce() -> R) {
     f();
 }