Make an editing pass and make all tests work

On the page for the never type fallback change, we've made a general
copyediting pass.  As part of this, we've also fixed all of the tests
such that they are checked and not simply ignored.

Strangely, some of the longer explanations that had been added to the
ignored tests were causing weird formatting issues in the rendered
output.  The example blocks weren't taking up the full width, and text
was flowing around them.  Making the tests work instead, and removing
these explanations, resolves this issue.

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

@@ -4,80 +4,98 @@
 
 ## Summary
 
-- Never type (`!`) to any type coercions fallback to never type (`!`).
+- Never type (`!`) to any type ("never-to-any") coercions fall back to never type (`!`) rather than to unit type (`()`).
 
 ## Details
 
-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:
+When the compiler sees a value of type `!` (never) in a [coercion site][], it implicitly inserts a coercion to allow the type checker to infer any type:
 
-```rust,ignore (has placeholders)
-// this
+```rust,should_panic
+# #![feature(never_type)]
+// This:
 let x: u8 = panic!();
 
-// is (essentially) turned by the compiler into
+// ...is (essentially) turned by the compiler into:
 let x: u8 = absurd(panic!());
 
-// where absurd is a function with the following signature
-// (it's sound, because `!` always marks unreachable code):
-fn absurd<T>(_: !) -> T { ... }
+// ...where `absurd` is the following function
+// (it's sound because `!` always marks unreachable code):
+fn absurd<T>(x: !) -> T { x }
 ```
 
 This can lead to compilation errors if the type cannot be inferred:
 
-```rust,ignore (uses code from previous example)
-// this
+```rust,compile_fail,E0282
+# #![feature(never_type)]
+# fn absurd<T>(x: !) -> T { x }
+// This:
 { panic!() };
 
-// gets turned into this
-{ absurd(panic!()) }; // error: can't infer the type of `absurd`
+// ...gets turned into this:
+{ absurd(panic!()) }; //~ ERROR can't infer the type of `absurd`
 ```
 
-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:
+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,ignore (has placeholders, uses code from previous example)
-type Fallback = /* An arbitrarily selected type! */;
+```rust,should_panic
+# #![feature(never_type)]
+# fn absurd<T>(x: !) -> T { x }
+type Fallback = /* An arbitrarily selected type! */ !;
 { absurd::<Fallback>(panic!()) }
 ```
 
-This is what is known as “never type fallback”.
+This is what is known as "never type fallback".
 
-Historically, the fallback type was `()`, causing confusing behavior where `!` spontaneously coerced to `()`, even when it would not infer `()` without the fallback.
+Historically, the fallback type has been `()` (unit).  This caused `!` to spontaneously coerce to `()` even when the compiler would not infer `()` without the fallback.  That was confusing and has prevented the stabilization of the `!` type.
 
-In the 2024 edition (and possibly in all editions on a later date) the fallback is now `!`.  This makes it work more intuitively, now when you pass `!` and there is no reason to coerce it to something else, it is kept as `!`.
+In the 2024 edition, the fallback type is now `!`.  (We plan to make this change across all editions at a later date.)  This makes things work more intuitively.  Now when you pass `!` and there is no reason to coerce it to something else, it is kept as `!`.
 
-In some cases your code might depend on the fallback being `()`, so this can cause compilation errors or changes in behavior.
+In some cases your code might depend on the fallback type being `()`, so this can cause compilation errors or changes in behavior.
 
-[coercion site]: https://doc.rust-lang.org/reference/type-coercions.html#coercion-sites
+[coercion site]: ../../reference/type-coercions.html#coercion-sites
 
 ## Migration
 
-There is no automatic fix, but there is automatic detection of code which will be broken by the edition change.  While still on a previous edition you should see warnings if your code will be broken.
+There is no automatic fix, but there is automatic detection of code that will be broken by the edition change.  While still on a previous edition you will see warnings if your code will be broken.
 
-In either case the fix is to specify the type explicitly, so the fallback is not used.  The complication is that it might not be trivial to see which type needs to be specified.
+The fix is to specify the type explicitly so that the fallback type is not used.  Unfortunately, it might not be trivial to see which type needs to be specified.
 
-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:
+One of the most common patterns broken by this change is using `f()?;` where `f` is generic over the `Ok`-part of the return type:
 
-```rust,ignore (can't compile outside of a result-returning function)
+```rust
+# #![allow(dependency_on_unit_never_type_fallback)]
+# fn outer<T>(x: T) -> Result<T, ()> {
 fn f<T: Default>() -> Result<T, ()> {
     Ok(T::default())
 }
 
 f()?;
+# Ok(x)
+# }
 ```
 
-You might think that in this example type `T` can't be inferred, however due to the current desugaring of `?` operator it used to be inferred to `()`, but it will be inferred to `!` now.
+You might think that, in this example, type `T` can't be inferred.  However, due to the current desugaring of the `?` operator, it was inferred as `()`, and it will now be inferred as `!`.
 
 To fix the issue you need to specify the `T` type explicitly:
 
-```rust,ignore (can't compile outside of a result-returning function, mentions function from previous example)
+<!-- TODO: edition2024 -->
+```rust
+# #![deny(dependency_on_unit_never_type_fallback)]
+# fn outer<T>(x: T) -> Result<T, ()> {
+# fn f<T: Default>() -> Result<T, ()> {
+#     Ok(T::default())
+# }
 f::<()>()?;
-// OR
+// ...or:
 () = f()?;
+# Ok(x)
+# }
 ```
 
-Another relatively common case is `panic`king in a closure:
+Another relatively common case is panicking in a closure:
 
-```rust,edition2015,should_panic
+```rust,should_panic
+# #![allow(dependency_on_unit_never_type_fallback)]
 trait Unit {}
 impl Unit for () {}
 
@@ -88,34 +106,45 @@ fn run<R: Unit>(f: impl FnOnce() -> R) {
 run(|| panic!());
 ```
 
-Previously `!` from the `panic!` coerced to `()` which implements `Unit`.  However now the `!` is kept as `!` so this code fails because `!` does not implement `Unit`.  To fix this you can specify return type of the closure:
-
-```rust,ignore (uses function from the previous example)
+Previously `!` from the `panic!` coerced to `()` which implements `Unit`.  However now the `!` is kept as `!` so this code fails because `!` doesn't implement `Unit`.  To fix this you can specify the return type of the closure:
+
+<!-- TODO: edition2024 -->
+```rust,should_panic
+# #![deny(dependency_on_unit_never_type_fallback)]
+# trait Unit {}
+# impl Unit for () {}
+#
+# fn run<R: Unit>(f: impl FnOnce() -> R) {
+#     f();
+# }
 run(|| -> () { panic!() });
 ```
 
-A similar case to the `f()?` can be seen when using a `!`-typed expression in a branch and a function with unconstrained return in the other:
+A similar case to that of `f()?` can be seen when using a `!`-typed expression in one branch and a function with an unconstrained return type in the other:
 
-```rust,edition2015
+```rust
+# #![allow(dependency_on_unit_never_type_fallback)]
 if true {
     Default::default()
 } else {
     return
 };
 ```
 
-Previously `()` was inferred as the return type of `Default::default()` because `!` from `return` got spuriously coerced to `()`.  Now, `!` will be inferred instead causing this code to not compile, because `!` does not implement `Default`.
+Previously `()` was inferred as the return type of `Default::default()` because `!` from `return` was spuriously coerced to `()`.  Now, `!` will be inferred instead causing this code to not compile because `!` does not implement `Default`.
 
 Again, this can be fixed by specifying the type explicitly:
 
+<!-- TODO: edition2024 -->
 ```rust
+# #![deny(dependency_on_unit_never_type_fallback)]
 () = if true {
     Default::default()
 } else {
     return
 };
 
-// OR
+// ...or:
 
 if true {
     <() as Default>::default()