Poor error message from try! or ? and type-mismatch

[nrc]

For try! we used to give a type mismatch message when the type of the value did not match the function type (see example below). We now give a message about the Carrier trait, which the user should not know about, e.g., error[E0277]: the trait bound(): std::ops::Carrieris not satisfied for the below example.

I removed the following from doc/error-index.md

Another situation in which this occurs is when you attempt to use the `try!`
macro inside a function that does not return a `Result<T, E>`:

```compile_fail,E0308
use std::fs::File;

fn main() {
    let mut f = try!(File::create("foo.txt"));
}

This code gives an error like this:

<std macros>:5:8: 6:42 error: mismatched types:
 expected `()`,
     found `core::result::Result<_, _>`
 (expected (),
     found enum `core::result::Result`) [E0308]

try! returns a Result<T, E>, and so the function must. But main() has
() as its return type, hence the error.

[durka]

Yeah, the error about Carrier is even worse than before (which even then was not enough to get users all the way to "I need to change this function to return a Result"). Should we make Carrier a lang item so it can be special-cased here?

[nikomatsakis]

This feels like a serious problem. This is an area where user confusion is common and it's a particular stumbling block for new users (the old message itself was a problem). I agree with @durka that it is probably worth special-casing here!

cc @wycats @jonathandturner

[sophiajt]

Is the special case here that it expects () as the output but sees a Result?

[durka]

@jonathandturner we should be able to go further than that, since the message says "in this expansion of try" (at least it used to -- in nightly this info has been lost in favor of "macro outside of the current crate"), e.g. it knows about the macro. In the case of ? the compiler obviously knows about that too.

[sophiajt]

@durka - sounds good

The macro backtrace should still be there for the try! case, so you could detect the type mismatch and before reporting it check the backtrace to see if we're calling through a try!

[durka]

If someone can give me a pointer on how to get the macro backtrace during error reporting, I can work on this.

[sophiajt]

@durka - you can check macro_backtrace in src/libsyntax/codemap.rs. Looks like it starts at about line 806.

Looks like E0308 is coming from report_and_explain_type_error in src/librustc/infer/error_reporting.rs. I think you should be able to dig through self.tcx.gcx.sess to get the codemap for the backtrace.

[carols10cents]

Is this the same as #35946?

[durka]

@carols10cents yes.

[sophiajt]

Close as a dupe of #35946