Result type inference breaks in 2024 edition, while working correctly in 2021 edition

[nazar-pc]

I tried this code:

fn foo() -> Result<(), u8> {
    Ok(())
}

fn test() -> Result<(), u8> {
    let f: fn() -> _ = foo as _;

    f()?;

    Ok(())
}

I expected to see this happen:

Type inference on f should work correctly.

Instead, this happened:

When switching to 2024 edition something odd is happening and inference results in confusing compilation error:

error[E0271]: type mismatch resolving `<Result<(), u8> as Try>::Output == !`
 --> src/lib.rs:7:5
  |
7 |     f()?;
  |     ^^^^ expected `!`, found `()`
  |
  = note:   expected type `!`
          found unit type `()`

The same code works fine on 2021 edition and I don't understand why 2024 breaks.

Replacing -> _ with explicit -> Result<(), u8> helps, but it is too verbose and hurts readability.

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=7f1158511f3560d231db70cb839340c4

Meta

rustc --version --verbose:

1.86.0-nightly

(2025-01-21 ed43cbcb882e7c06870a)

[purplesyringa]

This is not a 100% new bug, this fails on 2021:

fn foo() -> Result<i32, u8> {
    Ok(1)
}

fn test() -> Result<(), u8> {
    let f: fn() -> _ = foo as _;

    f()?;

    Ok(())
}

   Compiling playground v0.0.1 (/playground)
error[E0271]: type mismatch resolving `<Result<i32, u8> as Try>::Output == ()`
 --> src/lib.rs:8:5
  |
8 |     f()?;
  |     ^^^^ expected `()`, found `i32`

For more information about this error, try `rustc --explain E0271`.
error: could not compile `playground` (lib) due to 1 previous error

It surfaced with Result<(), _> "just" due to a never type fallback change, but inference has always been off.

[purplesyringa]

@rustbot label +A-coercions

It's the coercions+inference interaction once again

[theemathas]

Version that doesn't use the ? operator:

fn foo() -> Option<()> {
    Some(())
}

pub fn test() {
    let f: fn() -> _ = foo as _;
    let _ = match f() {
        Some(a) => a,
        None => panic!(),
    };
}

Using rust version 1.85.0-beta.5, this code compiles on edition 2021, but gives the following error on edition 2024:

error[E0605]: non-primitive cast: `fn() -> Option<()> {foo}` as `fn() -> Option<!>`
 --> src/lib.rs:6:24
  |
6 |     let f: fn() -> _ = foo as _;
  |                        ^^^^^^^^ invalid cast

For more information about this error, try `rustc --explain E0605`.

[theemathas]

Another version:

fn foo() -> () {}  // Changing the return type of this makes it also fail on edition 2021

pub fn test() {
    let f: fn() -> _ = foo as _;
    let _ = if true { f() } else { panic!() };
}

Error on edition 2024:

error[E0605]: non-primitive cast: `fn() {foo}` as `fn() -> !`
 --> src/lib.rs:4:24
  |
4 |     let f: fn() -> _ = foo as _;
  |                        ^^^^^^^^ invalid cast

For more information about this error, try `rustc --explain E0605`.

[WaffleLapkin]

Interestingly, this also fails:

fn foo() -> () {}

fn test() {
    let f = foo as fn() -> _; //~ error: non-primitive cast: `fn() {foo}` as `fn() -> !`
    if true { f() } else { panic!() };
}

so does this:

fn test() {
    let f: fn() -> _ = (|| ()) as _; //~ error: non-primitive cast: `{closure@src/lib.rs:4:25: 4:27}` as `fn() -> !`
    if true { f() } else { panic!() };
}

but not this:

fn foo() -> () {}

fn test() {
    let f = (|| ()) as fn() -> _; // OK
    if true { f() } else { panic!() };
    
    let f: fn() -> _ = || (); // OK
    if true { f() } else { panic!() };
    
    let f: fn() -> _ = foo; // OK
    if true { f() } else { panic!() };
}

so immediate solution for @nazar-pc is to just remove the cast:

fn foo() -> Result<(), u8> {
    Ok(())
}

fn test() -> Result<(), u8> {
    let f: fn() -> _ = foo;

    f()?;

    Ok(())
}

but we should probably investigate why some of these don't work. seems like we don't always propogate the return type of the function to all the affected inference vars before checking the if; and if the if sees just an unresolved inference variable it has nothing better than to unify it with the other branch.

[nazar-pc]

In real code I have a HashMap whose values are various methods with the same signature, which I cast to the a function pointer and I don't think casting is avoidable in this case. What I posted here is a reduced example that seemed to triggered the same behavior.

[WaffleLapkin]

@nazar-pc you should be able to come up with something. I found at least a couple ways to solve the problem with the hashmap like in your code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=2fa9b00d26affdca9a0100436c7cd988

[nazar-pc]

Thanks for the tips, but it is not blocking what I'm working on in any way, so I'm good as is