FutureResult inner type mismatch errors point to wrong line

[mqudsi]

Quite apart from rust-lang/rust#46606 but involving the same test code, an inner type mismatch in FutureResult chaining generates an error for one of mismatched types (which is a matter of some contention), but aside from which type triggers the error, the error ultimately points to the wrong location.

For example, in the code below:

    let f = future::result(Ok(()))
        .map_err(|()| "&'static str error")
        .map(|_| future::result(Err("another &'static str error")))
        .and_then(|_|
             future::result(Ok(())
                .map_err(|()| "String error".to_owned())
            )
        )
    ;

The error

13 |         .and_then(|_|
   |          ^^^^^^^^ expected struct `std::string::String`, found &str

points to the combinator resolving to a String, which:

• According to the compiler, String was the right result and the &'static str result was the wrong one, so if anything, the error should be on the map_err or map lines and not the and_then line, however,
• The error should actually point to the line of code that returned the &'str the compiler is complaining about, and not the function accepting the closure returning the wrong type.

(I imagine what is happening here is that and_then is an impl function being passed a FutureMap structure, and the compiler is finding a mismatch between the expected type passed to the the and_then function vs the actual inner type of FutureMap, and complaining at that juncture. Additionally, I no longer have any clue whether I should be posting criticism of compiler errors/hints while compiling against futures-rs here or in the rust-lang repo. Forgive me.)

[alexcrichton]

Thanks for the report! Isn't this a rustc bug though? (if at all?) I'm not sure there's anything we can do in this library to coerce the error messages?

[mqudsi]

Yeah, I wasn't sure whether to spam the rust issues with these errors or to keep them here.

I guess we can close this in favor of rust-lang/rust#46639

[alexcrichton]

Ok!