Terse diagnostic for never type fallback lint warning involving try operator and placeholder in path

[hniksic]

Compiling the following function warns in Rust 1.81 and later:

pub fn foo() -> std::io::Result<()> {
    [1, 2, 3]
        .into_iter()
        .map(|_| -> std::io::Result<_> { Ok(()) })
        .collect::<std::io::Result<_>>()?;
    Ok(())
}

I expected it to compile without warnings, as it did with previous Rust versions. It currently produces this warning:

warning: this function depends on never type fallback being `()`
 --> src/lib.rs:1:1
  |
1 | pub fn foo() -> std::io::Result<()> {
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #123748 <https://github.com/rust-lang/rust/issues/123748>
  = help: specify the types explicitly
note: in edition 2024, the requirement `!: FromIterator<()>` will fail
 --> src/lib.rs:5:20
  |
5 |         .collect::<std::io::Result<_>>()?;
  |                    ^^^^^^^^^^^^^^^^^^
  = note: `#[warn(dependency_on_unit_never_type_fallback)]` on by default

Playground

What is particularly perplexing about this warning is that I don't understand how the never type is even involved, as nothing in the code appears to diverge.

The current workaround is to add let () = ... before the iteration, which compiles without warnings:

// no warning
pub fn foo() -> std::io::Result<()> {
    let () = [1, 2, 3]
        .into_iter()
        .map(|_| -> std::io::Result<_> { Ok(()) })
        .collect::<std::io::Result<_>>()?;
    Ok(())
}

While this workaround works, it feels unnecessary and it's hard to explain and justify.

[fmease]

Triage: Works as intended. Edit: Let me explain.

[fmease]

The "culprit" is the _ inside .collect::<std::io::Result<_>>()? and the "trigger" is the try operator ?.

What is particularly perplexing about this warning is that I don't understand how the never type is even involved, as nothing in the code appears to diverge.

The try operator ? diverges on (here) Err. For Result, you can think of x? as expanding to the following¹:

match x { Ok(x) => x, Err(e) => return Err(e.into()), }

Notice the return which clearly diverges :)

So Rust <=2021 the aforementioned _ defaults/falls back to ()² because one the match arms diverges and nothing else constrains it, so the whole line means .collect::<std::io::Result<()>>()?.

In Rust >=2024 we want to fall back to ! in "these" cases (see #123748 for more details). However, as you can imagine ! doesn't implement FromIterator<()> contrary to () meaning your code won't compile in the 2024 edition (and onward). That's why this lint triggers. You can observe this by setting the edition to 2024 on the playground you've linked.

Footnotes

1. However the actual desugaring looks different and is more general. You can see it yourself by clicking the button labeled HIR on your playground. ↩

2. Note that it's not due to foo's return type std::io::Result<()> that it defaults to (). ↩

[fmease]

Instead of adding let () = / () = before [1, 2, 3], you can just make the following change (which looks more legible to me):

-         .collect::<std::io::Result<_>>()?;
+         .collect::<std::io::Result<()>>()?;

[hniksic]

Thanks for the detailed explanation and a nicer workaround. I cannot help but get an impression that, when this decision was being made, insufficient weight was given to the fact that a frequent and useful construct was now becoming an error. But I suppose that ship has sailed.

The proposed change is indeed much better than the let () = ... approach, and is what I'm now using in my code.

Finally, I'd like to point out that the diagnostic is really inadequate. I am very far from being a Rust beginner, and I was totally stumped by it. Speaking of "never type fallbacking to ()" seemed like a bug because the never type is usually associated with panicking and aborting, neither of which is not present here. A new or intermediate user will probably have no idea how to proceed given this diagnostic. If there is no such issue already, I'd like to seriously suggest that the compiler detect this issue in ? and provide a diagnostic more focused on that case.

[compiler-errors]

Here's a more minimal example:

pub fn foo() -> Result<(), ()> {
    match Ok(Default::default()) {
        Ok(k) => k,
        Err(e) => return Err(e),
    };
    Ok(())
}

I believe we can probably get a machine-applicable suggestion to change _ to (), and to turn Trait::method() into <() as Trait>::method(), and to annotate the type of variables to : () where possible. That should cover 99.9% of the cases, I would expect.