Higher ranked types in trait bounds result in confusing diagnostics

Code

trait Trait {}

impl Trait for for<'a> fn(&'a u32) {}

fn f() where for<'a> fn(&'a u32): Trait {}

fn main() {
    f();
}

Current output

error: implementation of `Trait` is not general enough
 --> ./t.rs:9:5
  |
9 |     f();
  |     ^^^ implementation of `Trait` is not general enough
  |
  = note: `for<'a> fn(&'a u32)` must implement `Trait`, for any lifetime `'0`...
  = note: ...but `Trait` is actually implemented for the type `for<'a> fn(&'a u32)`

Desired output

error: implementation of `Trait` is not general enough
 --> ./t.rs:9:5
  |
9 |     f();
  |     ^^^ implementation of `Trait` is not general enough
  |
  = note: `fn(&'0 u32)` must implement `Trait`, for any lifetime `'0`...
  = note: ...but `Trait` is actually implemented for the type `for<'a> fn(&'a u32)`
  = note: `where for<'a> fn(&'a u32): Trait` is parsed as `where for<'a> (fn(&'a u32): Trait)`, not `where (for<'a> fn(&'a u32)): Trait`

Rationale and extra context

for<'a> fn(&'a u32) in the note makes it seem like it is right (as it's the same as the type for which the trait is implemented), when we actually want to use the '0. Also it's a good idea to mention how the for binders in where clauses are parsed, since this is not that intuitive (the user could have literally pasted the type from the trait impl).

Other cases

No response

Rust Version

rustc 1.79.0-nightly (ef8b9dcf2 2024-04-24)
binary: rustc
commit-hash: ef8b9dcf23700f2e2265317611460d3a65c19eff
commit-date: 2024-04-24
host: x86_64-unknown-linux-gnu
release: 1.79.0-nightly
LLVM version: 18.1.4

Anything else?

No response

Compile the provided Rust example with the stated rustc nightly and compare the current and desired diagnostics. Trace the compiler path that produces the “implementation of Trait is not general enough” message. Done means the diagnostic uses the instantiated '0 lifetime and explains how the for binder in the where clause is parsed.