Unhelpful error messages for calls of methods defined in an impl with restricted bounds that aren't satisfied

[huonw]

struct Foo<T>(T);

impl<T> Foo<T> {
    fn new(x: T) -> Foo<T> { Foo(x) }

    // ... methods without restrictions ...

    fn restricted_good(&self) where T: Clone {}
}

impl<T: Clone> Foo<T> {
    fn restricted_bad(&self) {}
}

struct NotClone;

fn main() {
    let x = Foo::new(NotClone);
    x.restricted_good();
    x.restricted_bad();
}

<anon>:19:7: 19:24 error: the trait `core::clone::Clone` is not implemented for the type `NotClone`
<anon>:19     x.restricted_good();
                ^~~~~~~~~~~~~~~~~
<anon>:20:7: 20:23 error: type `Foo<NotClone>` does not implement any method in scope named `restricted_bad`
<anon>:20     x.restricted_bad();
                ^~~~~~~~~~~~~~~~

The _bad one is completely unhelpful, the _good is much better since it allows one to diagnose the problem. It would be nice for them both to be good.

This comes up relatively often with RefCell::<T, E>::unwrap (which requires E: Show in the impl), and Mutex::<T>::lock (which requires T: Send in the impl).

[huonw]

(A way to paper over this would be to move to where clauses in the standard library everywhere, although #20203 may mean that this is worse, at the moment.)

[nikomatsakis]

Comments from IRC:

[05:25:24] <nmatsakis> huon: no, but it's a tricky problem
[05:25:26] <nmatsakis> I think that falls under
[05:25:37] <nmatsakis> "method resolution should keep records near-misses"
[05:25:42] <nmatsakis> there've been a couple of other cases where I wanted that
[05:25:49] <nmatsakis> it does have a list of candidates
[05:25:58] <nmatsakis> so it's certainly plausible for it to do a better job
[05:26:03] <nmatsakis> and it could definitely keep track of
[05:26:06] <nmatsakis> candidates that it threw out
[05:26:11] <nmatsakis> beacuse of "winnowing" (evaluating the predicates)
[05:26:21] <nmatsakis> I like how gcc does this
[05:26:22] <huon> would effectively moving the bounds to where clauses on each method be invalid?
[05:26:30] <nmatsakis> well, that would be a workaround
[05:26:38] <nmatsakis> it might invalidate some coherence rules
[05:27:00] <nmatsakis> gcc often, when things don't resolve,
[05:27:04] <nmatsakis> gives you a list of all the things it considered
[05:27:07] <nmatsakis> and tells you why each one failed
[05:27:09] <nmatsakis> we could certainly do that too
[05:27:13] <nmatsakis> perhaps with some screening
[05:27:22] <nmatsakis> because right now there can be a LOT of obviously wrong candidates
[05:27:31] <nmatsakis> the other thing I want to do which is semi-related
[05:27:35] <nmatsakis> is to find traits that are not imported
[05:27:37] <nmatsakis> but which define the method in question
[05:27:40] <nmatsakis> and mention those
[05:27:40] <huon> yes!
[05:27:48] <huon> that's probably the biggest trait-related trip-up

[nikomatsakis]

I'd be happy to mentor this. For the record, the other bug is: #7643

[thchittenden]

Hi Niko, I'd like to take a stab at this. I was thinking that in the ProbeContext during method resolution we could keep track of the methods that were considered but did not fulfill the method constraints. Then when printing out the error we could notify the user that their type needs to fulfill whatever constraint it is. Does this seem like a viable strategy?

[gsingh93]

Any progress on this? I wasted a lot of time today trying to figure out why I couldn't call get on a HashMap when the method clearly exists, and then I realized I had forgotten to derive the right traits.

[gsingh93]

Can this be nominated for 1.0? This still seriously bugs me.