Skip to content
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

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

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 (`|args| { .. }`) 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 (`|args| { .. }`) 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-closures Area: closures (`|args| { .. }`) 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