|
| 1 | +# Never type fallback change |
| 2 | + |
| 3 | +## Summary |
| 4 | + |
| 5 | +- Never type (`!`) to any type ("never-to-any") coercions fall back to never type (`!`) rather than to unit type (`()`). |
| 6 | +- The `never_type_fallback_flowing_into_unsafe` lint is now `deny` by default. |
| 7 | + |
| 8 | +<!-- [`never_type_fallback_flowing_into_unsafe`]: ../../rustc/lints/listing/error-by-default.html#never-type-fallback-flowing-into-unsafe --> |
| 9 | + |
| 10 | +## Details |
| 11 | + |
| 12 | +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: |
| 13 | + |
| 14 | +```rust,should_panic |
| 15 | +# #![feature(never_type)] |
| 16 | +// This: |
| 17 | +let x: u8 = panic!(); |
| 18 | +
|
| 19 | +// ...is (essentially) turned by the compiler into: |
| 20 | +let x: u8 = absurd(panic!()); |
| 21 | +
|
| 22 | +// ...where `absurd` is the following function |
| 23 | +// (it's sound because `!` always marks unreachable code): |
| 24 | +fn absurd<T>(x: !) -> T { x } |
| 25 | +``` |
| 26 | + |
| 27 | +This can lead to compilation errors if the type cannot be inferred: |
| 28 | + |
| 29 | +```rust,compile_fail,E0282 |
| 30 | +# #![feature(never_type)] |
| 31 | +# fn absurd<T>(x: !) -> T { x } |
| 32 | +// This: |
| 33 | +{ panic!() }; |
| 34 | +
|
| 35 | +// ...gets turned into this: |
| 36 | +{ absurd(panic!()) }; //~ ERROR can't infer the type of `absurd` |
| 37 | +``` |
| 38 | + |
| 39 | +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: |
| 40 | + |
| 41 | +```rust,should_panic |
| 42 | +# #![feature(never_type)] |
| 43 | +# fn absurd<T>(x: !) -> T { x } |
| 44 | +type Fallback = /* An arbitrarily selected type! */ !; |
| 45 | +{ absurd::<Fallback>(panic!()) } |
| 46 | +``` |
| 47 | + |
| 48 | +This is what is known as "never type fallback". |
| 49 | + |
| 50 | +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. |
| 51 | + |
| 52 | +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 `!`. |
| 53 | + |
| 54 | +In some cases your code might depend on the fallback type being `()`, so this can cause compilation errors or changes in behavior. |
| 55 | + |
| 56 | +[coercion site]: ../../reference/type-coercions.html#coercion-sites |
| 57 | + |
| 58 | +### `never_type_fallback_flowing_into_unsafe` |
| 59 | + |
| 60 | +The default level of the `never_type_fallback_flowing_into_unsafe` lint has been raised from `warn` to `deny` in the 2024 Edition. This lint helps detect a particular interaction with the fallback to `!` and `unsafe` code which may lead to undefined behavior. See the link for a complete description. |
| 61 | + |
| 62 | +## Migration |
| 63 | + |
| 64 | +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. |
| 65 | + |
| 66 | +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. |
| 67 | + |
| 68 | +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: |
| 69 | + |
| 70 | +```rust |
| 71 | +# #![allow(dependency_on_unit_never_type_fallback)] |
| 72 | +# fn outer<T>(x: T) -> Result<T, ()> { |
| 73 | +fn f<T: Default>() -> Result<T, ()> { |
| 74 | + Ok(T::default()) |
| 75 | +} |
| 76 | + |
| 77 | +f()?; |
| 78 | +# Ok(x) |
| 79 | +# } |
| 80 | +``` |
| 81 | + |
| 82 | +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 `!`. |
| 83 | + |
| 84 | +To fix the issue you need to specify the `T` type explicitly: |
| 85 | + |
| 86 | +```rust,edition2024 |
| 87 | +# #![deny(dependency_on_unit_never_type_fallback)] |
| 88 | +# fn outer<T>(x: T) -> Result<T, ()> { |
| 89 | +# fn f<T: Default>() -> Result<T, ()> { |
| 90 | +# Ok(T::default()) |
| 91 | +# } |
| 92 | +f::<()>()?; |
| 93 | +// ...or: |
| 94 | +() = f()?; |
| 95 | +# Ok(x) |
| 96 | +# } |
| 97 | +``` |
| 98 | + |
| 99 | +Another relatively common case is panicking in a closure: |
| 100 | + |
| 101 | +```rust,should_panic |
| 102 | +# #![allow(dependency_on_unit_never_type_fallback)] |
| 103 | +trait Unit {} |
| 104 | +impl Unit for () {} |
| 105 | +
|
| 106 | +fn run<R: Unit>(f: impl FnOnce() -> R) { |
| 107 | + f(); |
| 108 | +} |
| 109 | +
|
| 110 | +run(|| panic!()); |
| 111 | +``` |
| 112 | + |
| 113 | +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: |
| 114 | + |
| 115 | +```rust,edition2024,should_panic |
| 116 | +# #![deny(dependency_on_unit_never_type_fallback)] |
| 117 | +# trait Unit {} |
| 118 | +# impl Unit for () {} |
| 119 | +# |
| 120 | +# fn run<R: Unit>(f: impl FnOnce() -> R) { |
| 121 | +# f(); |
| 122 | +# } |
| 123 | +run(|| -> () { panic!() }); |
| 124 | +``` |
| 125 | + |
| 126 | +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: |
| 127 | + |
| 128 | +```rust |
| 129 | +# #![allow(dependency_on_unit_never_type_fallback)] |
| 130 | +if true { |
| 131 | + Default::default() |
| 132 | +} else { |
| 133 | + return |
| 134 | +}; |
| 135 | +``` |
| 136 | + |
| 137 | +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`. |
| 138 | + |
| 139 | +Again, this can be fixed by specifying the type explicitly: |
| 140 | + |
| 141 | +```rust,edition2024 |
| 142 | +# #![deny(dependency_on_unit_never_type_fallback)] |
| 143 | +() = if true { |
| 144 | + Default::default() |
| 145 | +} else { |
| 146 | + return |
| 147 | +}; |
| 148 | +
|
| 149 | +// ...or: |
| 150 | +
|
| 151 | +if true { |
| 152 | + <() as Default>::default() |
| 153 | +} else { |
| 154 | + return |
| 155 | +}; |
| 156 | +``` |
0 commit comments