From 43d56e0a79665eddb15052b29390d248c3b8f68b Mon Sep 17 00:00:00 2001 From: Waffle Lapkin Date: Mon, 6 Apr 2026 23:09:44 +0200 Subject: [PATCH] ignore tests which will be broken by never type stabilization --- src/rust-2024/never-type-fallback.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/rust-2024/never-type-fallback.md b/src/rust-2024/never-type-fallback.md index db6b3ac2..2dbb0597 100644 --- a/src/rust-2024/never-type-fallback.md +++ b/src/rust-2024/never-type-fallback.md @@ -67,7 +67,7 @@ The fix is to specify the type explicitly so that the fallback type is not used. 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 +```rust,ignore # #![allow(dependency_on_unit_never_type_fallback)] # fn outer(x: T) -> Result { fn f() -> Result { @@ -98,7 +98,7 @@ f::<()>()?; Another relatively common case is panicking in a closure: -```rust,should_panic +```rust,should_panic,ignore # #![allow(dependency_on_unit_never_type_fallback)] trait Unit {} impl Unit for () {} @@ -125,7 +125,7 @@ run(|| -> () { panic!() }); 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 +```rust,ignore # #![allow(dependency_on_unit_never_type_fallback)] if true { Default::default()