Change:
<ins> error[E0283]: type annotations needed --> $DIR/issue-72690.rs:7:5 | LL |     String::from("x".as_ref()); |     ^^^^^^^^^^^^ cannot infer type for struct `std::string::String` | = note: cannot satisfy `std::string::String: std::convert::From<&_>` = note: required by `std::convert::From::from` error[E0282]: type annotations needed --> $DIR/issue-72690.rs:11:6 | LL |     |x| String::from("x".as_ref()); |      ^ consider giving this closure parameter a type error[E0283]: type annotations needed --> $DIR/issue-72690.rs:15:17 | LL |     let _ = "x".as_ref(); |                 ^^^^^^ cannot infer type for type `str` | = note: cannot satisfy `str: std::convert::AsRef<_>` error[E0283]: type annotations needed --> $DIR/issue-72690.rs:19:5 | LL |     String::from("x".as_ref()); |     ^^^^^^^^^^^^ cannot infer type for struct `std::string::String` | = note: cannot satisfy `std::string::String: std::convert::From<&_>` = note: required by `std::convert::From::from` error[E0283]: type annotations needed --> $DIR/issue-72690.rs:25:5 | LL |     String::from("x".as_ref()); |     ^^^^^^^^^^^^ cannot infer type for struct `std::string::String` | = note: cannot satisfy `std::string::String: std::convert::From<&_>` = note: required by `std::convert::From::from` error[E0283]: type annotations needed --> $DIR/issue-72690.rs:33:5 | LL |     String::from("x".as_ref()); |     ^^^^^^^^^^^^ cannot infer type for struct `std::string::String` | = note: cannot satisfy `std::string::String: std::convert::From<&_>` = note: required by `std::convert::From::from` error[E0283]: type annotations needed for `std::string::String` --> $DIR/issue-72690.rs:41:5 | LL |     String::from("x".as_ref()); |     ^^^^^^^^^^^^ cannot infer type for struct `std::string::String` LL |     let _ = String::from("x"); |         - consider giving this pattern a type | = note: cannot satisfy `std::string::String: std::convert::From<&_>` = note: required by `std::convert::From::from` error[E0283]: type annotations needed for `std::string::String` --> $DIR/issue-72690.rs:47:5 | LL |     let _ = String::from("x"); |         - consider giving this pattern a type LL |     String::from("x".as_ref()); |     ^^^^^^^^^^^^ cannot infer type for struct `std::string::String` | = note: cannot satisfy `std::string::String: std::convert::From<&_>` = note: required by `std::convert::From::from` error[E0283]: type annotations needed for `std::string::String` --> $DIR/issue-72690.rs:55:5 | LL |     let _ = String::from("x"); |         - consider giving this pattern a type ... LL |     String::from("x".as_ref()); |     ^^^^^^^^^^^^ cannot infer type for struct `std::string::String` | = note: cannot satisfy `std::string::String: std::convert::From<&_>` = note: required by `std::convert::From::from` error: aborting due to 9 previous errors Some errors have detailed explanations: E0282, E0283. For more information about an error, try `rustc --explain E0282`. </ins>

Discussion:
This compiles just fine: But this gives a compiler error: It seems really weird that the second statement is affected like this? Empty project (created with ), unmodified (so no extra dependencies): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is actually that the first statement has type error, but somehow the error is reported to the second statement. The first statement alone reports the error correctly and by fixing the error, the following compiles fine
This happens on Nightly and on Stable.
Labeling as this was a regression introduced by 1.41.0.
Assigning .
Problem seems to be that we always assume the last closure was the source of the inference failure
Just sticking a return after is enough to get the correct diagnostic in this specific instance. However, we clearly need to be smarter than that, as in a sequence of closures, any of them could be the source of an inference error (current implementation always assumes last, just adding a return always assumes first).
Definitely not the case - looking into some alternative fixes. claim
Ok this is even more subtle than I first thought. There's just far too much ambiguity here for this diagnostic code to produce a sensible suggestion. Any time a sub-expression/local pattern/argument pattern/closure's type contains the inference target it immediately becomes a candidate for suggesting on. In this case though, the inference target is , so any code that has anything to do with strings will trip the diagnostic...
Compiling the above results in this - clearly the has nothing to do with the error...
I have a similar message to: But what I don't understand is: why does it complain it can't infer the type if it clearly knows the type?