Skip to content

Misleading cannot infer type for type parameter #93198

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

Closed
Patryk27 opened this issue Jan 22, 2022 · 1 comment · Fixed by #97109
Closed

Misleading cannot infer type for type parameter #93198

Patryk27 opened this issue Jan 22, 2022 · 1 comment · Fixed by #97109
Assignees
Labels
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.

Comments

@Patryk27
Copy link
Contributor

Given the following code:

use std::collections::HashMap;

trait Store<K, V> {
    fn get_raw(&self, key: &K) -> Option<()>;
}

struct InMemoryStore;

impl<K> Store<String, HashMap<K, String>> for InMemoryStore {
    fn get_raw(&self, key: &String) -> Option<()> {
        None
    }
}

fn main() {
    InMemoryStore.get_raw(&String::default());
}

(playground link)

... the current output is:

error[E0282]: type annotations needed
  --> src/main.rs:16:19
   |
16 |     InMemoryStore.get_raw(&String::default());
   |                   ^^^^^^^ cannot infer type for type parameter `K`

This error message is a bit misleading in that it refers not to K from trait Store<K, V>, but K from the impl<K> Store<...> (the compiler is not sure which kind of HashMap<K, String> user wants).

Maybe we could print something like this?

error[E0282]: type annotations needed
  --> src/main.rs:16:19
   |
16 |     InMemoryStore.get_raw(&String::default());
   |                   ^^^^^^^ cannot infer type for type parameter `K`...
   |
  ::: src/main.rs:9
   |
 9 | impl<K> Store<String, HashMap<K, String>> for InMemoryStore {
          ^ ... from this impl
@Patryk27 Patryk27 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. labels Jan 22, 2022
@TaKO8Ki TaKO8Ki self-assigned this Mar 6, 2022
@returntoreality
Copy link

I have also an issue similar to this problem. In my case the function has two arguments with the same type signature, and so the error does not indicate which argument is actually causing the error. I think the error should:

  • tell the argument name and type (instead of just the type)
  • underline the actual argument and not the function name.

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 T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants