All callable types could have better error messages in the "no method found" case to suggest that you may have forgotten to actually call them

[bstrie]

Taking a real-life example from #rust today:

fn main() {
    let mut guess = String::new();
    std::io::stdin.read_line(&mut guess);
}

Yields the following error message:

<anon>:3:20: 3:41 error: no method named `read_line` found for type `fn() -> std::io::stdio::Stdin {std::io::stdio::stdin}` in the current scope
<anon>:3     std::io::stdin.read_line(&mut guess);
                            ^~~~~~~~~~~~~~~~~~~~~

The problem is that the code should read stdin().read_line rather than stdin.read_line, but the error message only hints at that. How hard would it be to add a note to all "no method found" errors when the type is callable?

[deej-io]

I feel like this would be a great way for me to simultaneously start getting to know the compiler and to contribute to rust, so I'd like to take a look at this this evening.

Would anyone be willing to mentor should I need it?

[bstrie]

@djrollins note that I only think that this should be an easy task, I don't have enough experience with the compiler to know that it's easy. :) Theoretically you should only need to find where the compiler is printing that specific error message, then add a "note" when the type mentioned in the error message implements any of Fn, FnMut, or FnOnce. You can look at many other error messages to see examples of "notes" being generated. Figuring out whether or not the type implements any of the Fn traits is probably going to be the trickiest part, because I'm not sure whether we have a convenient API to determine that for an arbitrary type. As a start you could merely implement the note only for bare functions (the fn() types) since they're always callable, though I'm not sure if it's actually any easier to distinguish fn from normal types compared to just looking up whether a type implements any of the callable traits.

For any compiler hacking, I'd recommend joining the #rust-internals IRC channel and casting around in there as you think of questions. That's also probably the best place to find a mentor. Good luck! :)

[deej-io]

I've given it a go trying to match the type to a TyBareFn as I wasn't sure how I could check for trait implementations with the information available on MethodError. Should I try and get someone to look at it on my fork or should I make a pull request?

[Manishearth]

There's a callable check here which you can try to use. Might be worth moving that out as a utility.

[Nashenas88]

@djrollins I actually wrote the portion of code referenced by @Manishearth. I wrote a blog post detailing the changes here, which should help out if you're unfamiliar with the compiler. There's no guarantee that those portions of the compiler will be the same, but from what I saw in @Manishearth's link, the important parts are still the same. I haven't worked with the compiler in a little while, but I should still be able to help explain some portions if you need help.

[deej-io]

Thank you all for all of the advice so far. @Nashenas88 I took the time to read your blog, it was a great read and very informative; I'm going to sit down and go through it again at the weekend before taking another punt at this issue.

[Manishearth]

Are you still working on this?

[deej-io]

Hey @Manishearth. Sorry, I've not actively looked at it for a while and let it slip away from me. I do want to carry on tackling this issue though if that's OK.

[vegai]

I'd like to give this a shot @Manishearth -- can I reach you in irc?

[Manishearth]

Yes, but @djrollins is already working on this.

Try #31686 instead?

[sophiajt]

@vegai - are you still working on this? I wouldn't mind picking it up if you've moved on, though if you're still working on it no worries :)

[Manishearth]

@jonathandturner this landed as #32053 / #32358 😄