Never type fallback change breaks code casting a function to `fn() -> _` when the inference variable is equated with a diverging variable
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
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.
Meta
rustc --version --verbose:
1.86.0-nightly
(2025-01-21 ed43cbcb882e7c06870a)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the linked Rust Playground reproducer and compare the 2021 and 2024 edition results using the reported rustc nightly version. Trace never-type fallback and function-pointer inference around let f: fn() -> _ = foo as _ and f()?; done when the 2024 example compiles like 2021 without an explicit return type.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100