30+ duplicates on E0308 with expected and found being literally identical

[hartwork]

Hi! 👋

I was about to report a compiler diagnostics bug and then noticed that this things has 30+ duplicates here going back until January 2019 that are 99% open as of the moment, and not strongly interlinked. The pattern is this:

1. Diagnostic "one type is more general than the other"
2. The details saying that the compiler literally got what they expected a la "note: expected " and "found ".
3. Often a reference to E0308 also

There is one concrete visual example with code further down.

After going through the first six pages of of matches for "one type is more general than the other" I stopped. Excluding unrelated ones, so far I found all of these as likely duplicates of this symptom:

• Poor error message related to higher rank lifetimes #37300
• Self-contradictory error message about Fn types on beta/nightly #57875
• Wrong Send constraint when using a trait with lifetime + associated type in async #60658
• Unhelpful error "one type is more general than the other" in async code #64650
• Why implementation of iterator is not generic enough in async context? #71671
• Async function leads to a "more general type" error #71723
• Weird nonsesnical 'one type is more general than the other' error #72063
• Unclear lifetime error in closure producing a future #74497
• Closure seemingly both implements and doesn't implement a trait #79187
• Bad Error Message: error[E0277]: the trait bound T: Generator<ResumeTy> is not satisfied #79648
• Confusing diagnostic when using closures #81511
• Inspect does not feed properly into map #81685
• Unable to pass hook to panic::set_hook as a variable or without specifying type #84296
• Confusing diagnostic - error[E0308]: mismatched types #84400
• "not general enough" error points to the async spawn site as opposed to the offending code #85516
• Functions/closures do not coerce to trait objects and give confusing diagnostics #87093
• Nonsensical diagnostic when returning closure #89620
• Rust complains about mismatched types, but the types are identical #89923
• "one type is more general than the other" error that appears to expect and find the same type #90656
• Problem with GATs, async, and Send-bounds #90696
• confusing error: "expected associated type" and "found associated type" are the same in some cases with Fn traits #91829
• Confusing compiler error for function taking closure returning reference #91966
• Unhelpful diagnostic for sort_by_key lifetime issue #92039
• E0308 expected and found are identical #97010
• Spurious "implementation of FnOnce is not general enough" error #99492
• Unhelpful diagnostic when infered lifetime of return value doesn't match parameter in closure #102400
• implied lifetimes lead to mismatched type error with seemingly identical types in the msg - async closure edition #108114
• Behavior of async fn and return position impl Future differs #109572
• "Implementation not general enough" with async and projection, fixed by wrapping with async move #110339
• rustc prints the same type as found and expected for function item whose signature includes references #111497
• error where expected and found future are the same #112010
• Passing mutating async function gives unhelpful duplicate type error #112855
• [E0308] one type is more general than the other: expected and found are reported as same #114849
• Expected and found traits show as identical for this code #114883
• Confusing error message: "Expected Foo, found Foo" #121944

Should one of these become the master issue?

Before you mass-close all the others, please verify that they are actual duplicates and didn't just fool me to believe they are.

Thank you!

---

PS: For completeness, my very broken diagnostics output was this, verbose rustc version included:

# cargo build
   Compiling issueXXX v0.1.0 (/tmp/tmp.5dilaGzlwK/issueXXX)
error[E0308]: mismatched types
   --> src/main.rs:9:14
    |
9   |         .arg(Arg::new("services").value_parser(parse_value))
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ one type is more general than the other
    |
    = note: expected trait `for<'a> <for<'a> fn(&'a str) -> Result<&'a str, &'a str> {parse_value} as FnOnce<(&'a str,)>>`
               found trait `for<'a> <for<'a> fn(&'a str) -> Result<&'a str, &'a str> {parse_value} as FnOnce<(&'a str,)>>`
note: the lifetime requirement is introduced here
   --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/clap_builder-4.3.8/src/builder/arg.rs:975:48
    |
975 |     pub fn value_parser(mut self, parser: impl IntoResettable<super::ValueParser>) -> Self {
    |                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

For more information about this error, try `rustc --explain E0308`.
error: could not compile `issueXXX` due to previous error

# rustc --version --verbose
rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-unknown-linux-gnu
release: 1.69.0
LLVM version: 15.0.7

And the related minimal reproducer code is this:

use clap::{Arg, Command};

fn parse_value(_text: &str) -> Result<&str, &str> {
    todo!()
}

fn main() {
    Command::new("rust-for-it")
        .arg(Arg::new("services").value_parser(parse_value))
        .get_matches();
}

[fmease]

I've just assigned myself but it will take a few weeks until I'll actually have the time to look into fixing this (I need to clear my review backlog, finish several PRs of mine and work on other issues I'm assigned to).

[fmease]

As a side note, I'd like us to keep any “gray” issues (closed as not duplicate) in the list to be able to double-check if the future fix 🤞 addresses all reported instances.

[metasim]

Is there a workaround recipe when running into this issue? I can't say I understand what triggers it or how to direct the compiler in a different direction.