Skip to content

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 #29124

@bstrie

Description

@bstrie
Contributor

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?

Activity

changed the title [-]All callable types could have better error messages in the "no method found" case to suggest that you may have forgotten to actuall call them[/-] [+]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[/+] on Oct 17, 2015
added
A-diagnosticsArea: Messages for errors, warnings, and lints
E-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
on Oct 17, 2015
deej-io

deej-io commented on Oct 19, 2015

@deej-io
Contributor

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

bstrie commented on Oct 22, 2015

@bstrie
ContributorAuthor

@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

deej-io commented on Oct 28, 2015

@deej-io
Contributor

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

Manishearth commented on Nov 16, 2015

@Manishearth
Member

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

Nashenas88

Nashenas88 commented on Nov 19, 2015

@Nashenas88
Contributor

@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

deej-io commented on Dec 2, 2015

@deej-io
Contributor

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.

added
E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
on Feb 29, 2016
Manishearth

Manishearth commented on Feb 29, 2016

@Manishearth
Member

Are you still working on this?

deej-io

deej-io commented on Mar 1, 2016

@deej-io
Contributor

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

vegai commented on Mar 1, 2016

@vegai
Contributor

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

Manishearth

Manishearth commented on Mar 1, 2016

@Manishearth
Member

Yes, but @djrollins is already working on this.

Try #31686 instead?

sophiajt

sophiajt commented on Mar 21, 2016

@sophiajt
Contributor

@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

Manishearth commented on Mar 22, 2016

@Manishearth
Member

@jonathandturner this landed as #32053 / #32358 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-diagnosticsArea: Messages for errors, warnings, and lintsE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @vegai@sophiajt@bstrie@Manishearth@Nashenas88

        Issue actions

          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 · Issue #29124 · rust-lang/rust