Error messages should indicate when a method is missing due to unsatisfied constraints

[DanielKeep]

I've been seeing more and more questions along the lines of this StackOverflow question. A user tries to call a method that is in the docs, but the compiler insists it doesn't exist. It turns out that this is because the method is only implemented provided certain generic constraints are satisfied, but they aren't.

The compiler does not mention this.

The only way a new user would find out about this is if they scroll up from the documentation on the method, and realise that the impl... header applies to everything below it, which isn't immediately obvious.

I think that the compiler should make a bit more of an effort here: if there is a method with the given name, but it doesn't satisfy one or more constraints, the compiler should at least add a note along the lines of:

Method exists, but one or more constraints are not satisfied.

Preferably, it would change the whole error from:

type `core::result::Result<u32, Error>` does not implement any method in scope named `unwrap`

To something like:

error: method `unwrap` is unavailable due to unsatisfied constraints for type `core::result::Result<u32, Error>`
note: `unwrap` requires: `Error: Debug`.

(Language mangled a bit to put the potentially long type name at the end.)

[jroesch]

This may be more complicated to do then it seems. I'll look into it though, would be nice to help guide users though.

[DanielKeep]

Comment from Matthieu M. on Stack Overflow:

Clang manages it with SFINAE exclusion on template methods in C++, which is fairly similar (since SFINAE is about culling methods depending on some conditions). This not only means the feature is actually implementable, but may also provide a reference implementation for a would-be implementer.

[jroesch]

Yeah I believe that it is definitely implementable, just not sure if the internals are currently factored in such a way that will allow us to do this easily. I hope to have some time to generally improve trait resolution and indirectly error reporting this summer. Of course if some one else has a patch I'm sure everyone would be interested 😄

[arthurprs]

Big +1 to this, lots of people are bit by this.

Including me: https://internals.rust-lang.org/t/better-error-message-when-method-name-matches-but-not-the-where-clause/1779

[apasel422]

This seems to have been fixed by #26435:

struct Foo;

fn get_res() -> Result<&'static str, Foo> { Ok("ok") }

fn main() {
    let res1 = get_res();
    assert!(res1.is_ok());
    assert_eq!("just for test", res1.unwrap());
}

Output:

> rustc --version
rustc 1.3.0-nightly (e4e93196e 2015-07-14)
> rustc foo.rs
foo.rs:8:38: 8:46 error: no method named `unwrap` found for type `core::result::Result<&str, Foo>` in the current scope
foo.rs:8     assert_eq!("just for test", res1.unwrap()); //error
                                              ^~~~~~~~
<std macros>:1:1: 9:39 note: in expansion of assert_eq!
foo.rs:8:5: 8:48 note: expansion site
foo.rs:8:38: 8:46 note: the method `unwrap` exists but the following trait bounds were not satisfied: `Foo : core::fmt::Debug`

[nham]

I'm wondering if this message could be improved further. It seems confusing to me for it to say no method named unwrap found ..., followed later by the method unwrap exists but ...

[brson]

Since this is an old bug, there's a claim that it was fixed, and diagnostics have changed a lot, closing. Please open with updated suggestions based on current rustc.