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

Misleading note for accessing closures within structs. #32128

Closed
ix opened this issue Mar 8, 2016 · 5 comments
Closed

Misleading note for accessing closures within structs. #32128

ix opened this issue Mar 8, 2016 · 5 comments
Labels
A-diagnostics Area: Messages for errors, warnings, and lints

Comments

@ix
Copy link

ix commented Mar 8, 2016

Hi, I encountered an issue the other day wherein I was attempting to call a closure stored within a struct.

The compiler gives a misleading error which doesn't give the user an idea on how to fix the problem.
I've prepared an example which reproduces the misleading text:

struct Example {
    example: Box<Fn(i32) -> i32>
}

fn main() {
    let demo = Example {
        example: Box::new(|x| {
            x + 1
        })
    };

    demo.example(1);
    // (demo.example)(1);
}

The error this yields from the compiler is as follows:

structs.rs:12:10: 12:20 error: no method named `example` found for type `Example` in the current scope
structs.rs:12     demo.example(1);
                       ^~~~~~~~~~
structs.rs:12:10: 12:20 note: did you mean to write `demo.example`?
structs.rs:12     demo.example(1);
                       ^~~~~~~~~~
error: aborting due to previous error

Note that in the source code I've provided, underneath the line which yields this error, I have provided a comment demonstrating the correct way to access and call the example member of the structure, however the compiler's example is identical to the erroneous code and thus doesn't help the user in working out how to properly call the member.

Would it be at all possible to improve this error message?

I've confirmed this is reproducible on rustc 1.7.0 (a5d1e7a59 2016-02-29).

@Aatch
Copy link
Contributor

Aatch commented Mar 9, 2016

If I'm right, we should be able to check to see if the field implements one of the Fn* traits and alter the error message based on that.

@durka
Copy link
Contributor

durka commented Mar 9, 2016

The check already exists, but it only checks for FnOnce and doesn't try deref coercions (which you will need if you want to catch Box<Fn()>).

@Aatch
Copy link
Contributor

Aatch commented Mar 9, 2016

@durka as far as I know anything that implements any of the Fn* traits will implement FnOnce, (since if you can call it more than once, you can clearly call just once). So it's just a matter of checking deref too.

@durka
Copy link
Contributor

durka commented Mar 10, 2016

@Aatch is it feasible to start up the deref machinery just for a note in an error message? I don't really know how that stuff works.

@steveklabnik steveklabnik added the A-diagnostics Area: Messages for errors, warnings, and lints label Mar 11, 2016
@eddyb
Copy link
Member

eddyb commented Mar 12, 2016

@durka it's a single call, search for autoderef in typeck.

Manishearth added a commit to Manishearth/rust that referenced this issue Apr 5, 2016
…r-fn-ty, r=nagisa

Autoderef when suggesting to call `(self.field)`

Fixes rust-lang#32128
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
Projects
None yet
Development

No branches or pull requests

5 participants