Unclear error message recommending the same wrong code

[sunjay]

Rust Playground Link: https://is.gd/1A99qU

I was in the middle of coming up with a toy example so I could ask someone how I can call a function stored in Rc when I noticed this:

<anon>:16:21: 16:22 error: no method named `f` found for type `Foo` in the current scope
<anon>:16     let value = foo.f(vec![1, 2, 3]);
                              ^
<anon>:16:21: 16:22 note: did you mean to write `foo.f`?
<anon>:16     let value = foo.f(vec![1, 2, 3]);

On the third line of the error message, it says "did you mean to write foo.f?" Then on the next line, it shows that I did in fact write foo.f(...). This is clearly incorrect as it would result in the same code.

Here's the code that is causing the problem:

use std::rc::Rc;

type Func = Rc<Fn(Vec<usize>) -> usize>;

struct Foo {
    a: usize,
    f: Func,
}

fn main() {
    let foo = Foo {
        a: 22,
        f: Rc::new(|x| x.len()),
    };

    let value = foo.f(vec![1, 2, 3]);
    println!("{}", value);
}

Now that I am writing all of this out, I think the error message is suggesting that I write only foo.f and get the property instead of calling it as a function. If that's the case, then the error message should probably be clarified because that is not clear from the current message in this case.

---

Since I wrote this on the Rust Playground using the stable version of Rust, I assume that the version info is around the same as my local version which is also running the latest Rust:

rustc 1.9.0 (e4e8b6668 2016-05-18)
binary: rustc
commit-hash: e4e8b666850a763fdf1c3c2c142856ab51e32779
commit-date: 2016-05-18
host: x86_64-unknown-linux-gnu
release: 1.9.0

[hanna-kruppe]

There's a suggestion that is supposed to tell you that you can call the function as (foo.f)(args...), but it seemingly didn't get triggered in this case. On beta and nightly it does trigger though:

<anon>:16:21: 16:22 note: use `(foo.f)(...)` if you meant to call the function stored in the `f` field
<anon>:16     let value = foo.f(vec![1, 2, 3]);
                              ^

So this bug is apparently fixed already. (I recall seeing a PR that improved this diagnostic but I can't find it know.)

Thanks for reporting though!

[hanna-kruppe]

I think I found the PR: #32712

[sunjay]

Great! If this is fixed in nightly, should this issue be closed or remain open until that is stable?

[hanna-kruppe]

The usual policy is to close when it's fixed on nightly.

[sunjay]

Makes sense. Thanks for looking into this!