Skip to content

type annotations needed for if let Some(whatever) = todo!() { not very helpful #141742

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
matthiaskrgr opened this issue May 29, 2025 · 4 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference A-patterns Relating to patterns and pattern matching D-lack-of-suggestion Diagnostics: Adding a (structured) suggestion would increase the quality of the diagnostic. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@matthiaskrgr
Copy link
Member

matthiaskrgr commented May 29, 2025

Code

fn main() {
    if let Some(whatever) = todo!() {
        todo!();
    } else {
        todo!();
    }
}

Current output

error[E0282]: type annotations needed
 --> src/main.rs:2:17
  |
2 |     if let Some(whatever) = todo!() {
  |                 ^^^^^^^^ cannot infer type

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

It's not really clear how rustc would like to see the type annotations, without adding an extra binding and without type_ascription

What does not work:

if let Some(whatever): Option<i32> = todo!() {
or
if let Some(whatever: i32) = todo!() {

what did end up working:

if let Some(x) = Some(todo!()) {
or
if let Some(x @ ()) = todo!() {

zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/type.20annotations.20needed.20.60if.20let.20Some.28x.29.20.3D.20todo!.28.29.60/with/521126024

Rust Version

rustc 1.89.0-nightly (6f6971078 2025-05-28)
binary: rustc
commit-hash: 6f69710780d579b180ab38da4c1384d630f7bd31
commit-date: 2025-05-28
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5
@matthiaskrgr matthiaskrgr added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-patterns Relating to patterns and pattern matching labels May 29, 2025
@jhpratt
Copy link
Member

jhpratt commented May 29, 2025

My first thought was to annotate Some, which turns out to work.

fn main() {
    if let Some::<()>(whatever) = todo!() {
        todo!();
    } else {
        todo!();
    }
}

@matthiaskrgr
Copy link
Member Author

mmh maybe it makes sense to make the diagnostic span the entire Some(...) ? 🤔

@jhpratt
Copy link
Member

jhpratt commented May 29, 2025

I think so. It is the Option that needs the annotating, technically.

@fmease
Copy link
Member

fmease commented May 30, 2025

If I'm reading the messages of both of you correctly, you seem to be interpreting the type annotations needed plus the primary highlight as "type annotations needed exactly where the highlight resides" (apologies if that's not the case).

Whereas I'm quite certain that this diagnostic simply points to the location that's in some way associated with a type (type variable) that couldn't be inferred (solved).

And I go as far as saying that that's how you should interpret it. For illustrative/pedagogical purposes only, this is how I read this diagnostic:

error[E0282]: cannot infer a type at this place
 --> src/main.rs:2:17
  |
2 |     if let Some(whatever) = todo!() {
  |                 ^^^^^^^^ cannot infer a type at this place
  |
  = help: consider adding a type annotation somewhere in the vicinity
          where "type annotation" not only includes `: $ty` but
          also `as` casts, generic argument lists or anything really
          that can narrow down the types in some way

Don't get me wrong,

  1. it would be nice if we could suggest consider specifying a type here: Some::</* Type */>(whatever) here.
  2. I think the phrasing of the primary message and of the label could be made a lot better / clearer assuming that I guessed correctly about the misunderstanding it may cause. I'm pretty used to it, so it's hard for me to see and reevaluate it from an outsider's perspective (I'm not implying that you are outsiders lol, you certainly aren't)

@fmease fmease added A-inference Area: Type inference D-lack-of-suggestion Diagnostics: Adding a (structured) suggestion would increase the quality of the diagnostic. labels May 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference A-patterns Relating to patterns and pattern matching D-lack-of-suggestion Diagnostics: Adding a (structured) suggestion would increase the quality of the diagnostic. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants