Skip to content

Bad error message when closure parameter type can't be inferred #71732

New issue

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

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

Already on GitHub? # to your account

Closed
rbtcollins opened this issue May 1, 2020 · 4 comments · Fixed by #78265
Closed

Bad error message when closure parameter type can't be inferred #71732

rbtcollins opened this issue May 1, 2020 · 4 comments · Fixed by #78265
Labels
A-closures Area: Closures (`|…| { … }`) A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@rbtcollins
Copy link
Contributor

rbtcollins commented May 1, 2020

This is either a regression of #45685 or it was closed prematurely.

Fairly minimal reproducer:

use std::collections::hash_map::HashMap;

fn foo(parameters: &HashMap<String, String>) -> bool {
    parameters
        .get(&"key".into())
        .and_then(|found: &String| {
            Some(false)
        })
        .unwrap_or(false)
}

->

error[E0283]: type annotations needed for `&std::string::String`
 --> src/lib.rs:6:20
  |
6 |         .and_then(|found: &String| {
  |                    ^^^^^ consider giving this closure parameter the explicit type `&std::string::String`, where the type parameter `std::string::String` is specified
  |
  = note: cannot resolve `std::string::String: std::borrow::Borrow<_>`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0283`.
error: could not compile `playground`.

To learn more, run the command again with --verbose.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c8754ceba0148a4da807002ae99ffa25

I'm still not entirely sure what is actually wrong here - is it the lifetime as in #22340? Anyhow - the message doesn't refer to any T that needs to be specified, and the named explicit type is not sufficient to fix the issue even when given.

Happens with nightly too.

@rbtcollins
Copy link
Contributor Author

Right, so the triggering problem here is the get() call - with that fixed it all falls into place, but the error message is still poor.

@jonas-schievink jonas-schievink added A-closures Area: Closures (`|…| { … }`) A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 1, 2020
@adaszko
Copy link
Contributor

adaszko commented Aug 26, 2020

Right, so the triggering problem here is the get() call - with that fixed it all falls into place, but the error message is still poor.

I got hit by this bug too and in my case the fix isn't obvious (it's a mix of an iterator and take_while()). What did you mean by "fixing the get() call"?

@rbtcollins
Copy link
Contributor Author

It has a parameter type that is a bit bonkers given the type of the Hash, which causes the type inference of the into() to go off into the weeds I think; doesn't change that there is a bug - this is about the diagnostics after all.

use std::collections::hash_map::HashMap;

fn foo(parameters: &HashMap<String, String>) -> bool {
    parameters
        .get("key")
        .and_then(|_found: &String| {
            Some(false)
        }).unwrap_or(false)
}

is a fixed version of the broken code.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b4332041d4727de8e53025cf2aee89cb

@lcnr lcnr added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Oct 20, 2020
@lcnr
Copy link
Contributor

lcnr commented Oct 20, 2020

The error message should have been fixed by #78111, marking as E-needs-test.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-closures Area: Closures (`|…| { … }`) A-diagnostics Area: Messages for errors, warnings, and lints A-inference Area: Type inference C-enhancement Category: An issue proposing an enhancement or a PR with one. E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. 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.

4 participants