Misplaced error on ambiguous Borrow impl

[Nadrieril]

I tried this code (playground):

#[derive(Debug, Clone, Eq, PartialEq, Hash)]
struct Label(String);

impl std::borrow::Borrow<str> for Label {
    fn borrow(&self) -> &str {
        self.0.as_ref()
    }
}
impl<'a> From<&'a str> for Label {
    fn from(s: &'a str) -> Self {
        Label(s.to_string())
    }
}

use std::collections::HashMap;

fn main() {
    let foo: HashMap<Label, ()> = Default::default();
    let _ = foo.get(&"k".into());
    let _ = foo.iter().map(|(k, v): (&Label, _)| ()).count();
}

I initially didn't have the Borrow impl, so the foo.get line was unambiguous. When I added the impl, that line became ambiguous, because the .into() could mean into Label or into String. I expected the compiler to report that; instead, I got a nonsensical error on the following line:

error[E0283]: type annotations needed for `(&Label, &())`
  --> src/main.rs:20:29
   |
20 |     let _ = foo.iter().map(|(k, v): (&Label, _)| ()).count();
   |                             ^^^^^^ consider giving this closure parameter the explicit type `(&Label, &())`, where the type parameter `Label` is specified
   |
   = note: cannot satisfy `Label: std::borrow::Borrow<_>`

Note how it mentions Borrow even though nothing needs Borrow on that line. Note also how it asks for a concrete type even though it is already concrete.

Meta

I originally got the error on stable but it fails in the playground on nightly too.

[Nadrieril]

Minimized a bit:

use std::borrow::Borrow;

struct Label(String);

impl Borrow<str> for Label {
    fn borrow(&self) -> &str {
        self.0.as_ref()
    }
}
impl<'a> From<&'a str> for Label {
    fn from(s: &'a str) -> Self {
        Label(s.to_string())
    }
}

fn get<Q: ?Sized>(k: &Q)
where
    Label: Borrow<Q>,
{
}

fn iter(f: impl FnMut(Label)) {}

fn main() {
    get(&"k".into());
    iter(|k: Label| ());
}

(play)

I thought it was specific to HashMap and Borrow but it doesn't look like it anymore. It fails even when there is no link between the two lines at all. There's something about using the same type twice where one is ambiguous somehow.

[Nadrieril]

Ah, this is duplicate with #70082 and #69455 that I hadn't found before. Closing in favor of those.