Error message ascii art pointer / arrow points to wrong argument

[mkmik]

Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8b21d823468da1cb8ba7442d8b4e0e85

fn foo(x: u32, a: impl Into<String>, y: u32, b: impl Into<String>) {
    println!("fox: a={}, b={}", a.into(), b.into());
}

fn main() {
    let bar: String = "bar".to_string();
    let baz: &str = "baz";

    for (a, b) in &[(&bar, baz)] {
        let a: &String = a;
        foo(42, a, 43, b);
    }
}

The current output is:

/Users/mkm/.cargo/bin/cargo play --cargo-option=--color=always /var/folders/zp/pk0v2q4x39z43k91vst1_jsc0000gn/T/scratch.rs
   Compiling p3ofvf9avhdc8sbzh9blgjf7wwnoz v0.1.0 (/var/folders/zp/pk0v2q4x39z43k91vst1_jsc0000gn/T/cargo-play.3oFVf9AvHdC8sbzH9BLGJf7wwnoz)
error[E0277]: the trait bound `String: From<&&str>` is not satisfied
  --> src/main.rs:11:17
   |
1  | fn foo(x: u32, a: impl Into<String>, y: u32, b: impl Into<String>) {
   |                                                      ------------ required by this bound in `foo`
...
11 |         foo(42, a, 43, b);
   |                 ^ the trait `From<&&str>` is not implemented for `String`
   |
   = help: the following implementations were found:
             <String as From<&String>>
             <String as From<&mut str>>
             <String as From<&str>>
             <String as From<Box<str>>>
           and 2 others
   = note: required because of the requirements on the impl of `Into<String>` for `&&str`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `p3ofvf9avhdc8sbzh9blgjf7wwnoz`

To learn more, run the command again with --verbose.

Ideally the output should look like:

/Users/mkm/.cargo/bin/cargo play --cargo-option=--color=always /var/folders/zp/pk0v2q4x39z43k91vst1_jsc0000gn/T/scratch.rs
   Compiling p3ofvf9avhdc8sbzh9blgjf7wwnoz v0.1.0 (/var/folders/zp/pk0v2q4x39z43k91vst1_jsc0000gn/T/cargo-play.3oFVf9AvHdC8sbzH9BLGJf7wwnoz)
error[E0277]: the trait bound `String: From<&&str>` is not satisfied
  --> src/main.rs:11:17
   |
1  | fn foo(x: u32, a: impl Into<String>, y: u32, b: impl Into<String>) {
   |                                                      ------------ required by this bound in `foo`
...
11 |         foo(42, a, 43, b);
   |                        ^ the trait `From<&&str>` is not implemented for `String`
   |
   = help: the following implementations were found:
             <String as From<&String>>
             <String as From<&mut str>>
             <String as From<&str>>
             <String as From<Box<str>>>
           and 2 others
   = note: required because of the requirements on the impl of `Into<String>` for `&&str`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `p3ofvf9avhdc8sbzh9blgjf7wwnoz`

To learn more, run the command again with --verbose.

I tried on stable (1.52.1) , beta and nightly (on rust playground and locally).

It seems to confuse only when there are multiple arguments of the same type (e.g. the impl Into<String> here.
I didn't try with other types.

[jam1garner]

This bug seems like a weird mix of things... the bug in question is present here:

rust/compiler/rustc_typeck/src/check/fn_ctxt/checks.rs

Lines 911 to 925 in 9814e83

	let mut referenced_in = final_arg_types
	.iter()
	.map(|&(i, checked_ty, _)| (i, checked_ty))
	.chain(final_arg_types.iter().map(|&(i, _, coerced_ty)| (i, coerced_ty)))
	.flat_map(|(i, ty)| {
	let ty = self.resolve_vars_if_possible(ty);
	// We walk the argument type because the argument's type could have
	// been `Option<T>`, but the `FulfillmentError` references `T`.
	if ty.walk().any(|arg| arg == predicate.self_ty().into()) {
	Some(i)
	} else {
	None
	}
	})
	.collect::<Vec<usize>>();

It looks like ty.walk().any(|arg| arg == predicate.self_ty().into()) is searching for the predicate <std::string::String as std::convert::From<&&str>>, but the way it's searching for it is by looking for references to std::string::String (the self_ty of the predicate).

But since the argument types look like:

(u32, &std::string::String, u32, &&str)

it means that walking each type and looking for std::string::String will only match against it for &std::string::String... but the problem is, I don't think the self_ty of the predicate is the item of interest? This implementation seems like a heuristic at best and I'm not sure I'm familiar enough with trait resolution internals to handle this problem.

But the steps seem to be something like:

1. Compiler sees that the argument must implement Into<String>. It goes "ok for T to implement Into, String must implement From"
2. So the compiler sees &&str being passed as Into<String>, and so it goes "ok does 'String' implement From<&&str>" and it goes: no, no it doesn't
3. And it goes "ok fire off a diagnostic for a String argument not implementing From<&&str>"
4. When it tries to fire off that diagnostic, it sees that there is, in fact, a String in one of the arguments, it goes, ah! this must be the String that doesn't implement From<&&str> and fires off the lint pointing at the wrong argument.

My best guess on how to fix this, which I will look into more tomorrow, is to modify step 3 to look more like "ok so String doesn't implement From<&&str>, why did I care about that again?" and it goes "ah yes in order for &&str to satisfy Into<String>, fire off a diagnostic for an &&str that it doesn't implement Into<String>".

I think part of the problem with that implementation is that like....

^ the trait `From<&&str>` is not implemented for `String`

this text would likely be modified by that? And I'm not certain if that's preferable. I personally don't find it all that great for it to resolve through.

This is the full diagnostic, for reference:

error[E0277]: the trait bound `String: From<&&str>` is not satisfied
  --> src/main.rs:21:17
   |
1  | fn foo(x: u32, a: impl Into<String>, y: u32, b: impl Into<String>) {
   |                                                      ------------ required by this bound in `foo`
...
21 |         foo(42, a, 43, b);
   |                 ^ the trait `From<&&str>` is not implemented for `String`
   |
   = help: the following implementations were found:
             <String as From<&String>>
             <String as From<&mut str>>
             <String as From<&str>>
             <String as From<Box<str>>>
           and 2 others
   = note: required because of the requirements on the impl of `Into<String>` for `&&str`

While I do think this is good for expressing requirement chains, I don't feel the primary label is all that user-friendly. I've seen a lot of beginners go "doesn't implement From<&&str>" but it doesn't need that, this is supposed to be Into<String>"? Especially when it comes to 3rd party crates, where such a trait-chain would be less familiar/obvious.

[mkmik]

Oh yes, if as a bonus we also get the error message to reference the type of the formal parameter, as present in the signature, this would be nice, although it wouldn't help here.

I'm unfamiliar with the codebase. A naive question though: can't the compiler keep some context as to which parameter (index) it's being processed so that when the diagnostic is fired off it doesn't have to find it again?

[estebank]

Current output:

error[E0277]: the trait bound `String: From<&&str>` is not satisfied
  --> src/main.rs:11:24
   |
11 |         foo(42, a, 43, b);
   |         ---            ^ the trait `From<&&str>` is not implemented for `String`
   |         |
   |         required by a bound introduced by this call
   |
   = help: consider casting the `&&str` value to `&str`
   = note: required for `&&str` to implement `Into<String>`
note: required by a bound in `foo`
  --> src/main.rs:1:54
   |
 1 | fn foo(x: u32, a: impl Into<String>, y: u32, b: impl Into<String>) {
   |                                                      ^^^^^^^^^^^^ required by this bound in `foo`
help: consider dereferencing here
   |
11 |         foo(42, a, 43, *b);
   |                        +

The issue seems to be resolved. Let's ensure we have a test for it in the suite and close the ticket.

[SzilvasiPeter]

@rustbot claim

[rustbot]

Error: The "Ready" shortcut only works on pull requests.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #triagebot on Zulip.