async fn doesn't compile if it includes at least two generic lifetimes and at least one 'static lifetime

[Lucretiel]

I tried this code:

async fn frobnicate(_a: &str, _b: &bool, _c: &'static i32) {}

I expected to see this happen: It compiles successfully

Instead, this happened: explanation: It fails to compile with this error message:

error[[E0700]](https://doc.rust-lang.org/stable/error-index.html#E0700): hidden type for `impl Trait` captures lifetime that does not appear in bounds
 --> src/lib.rs:2:60
  |
2 | async fn frobnicate(_a: &str, _b: &bool, _c: &'static i32) {}
  |                                                            ^^
  |
  = note: hidden type `impl Future<Output = ()>` captures lifetime '_#23r

Details

This bug appears on any async function that includes at least two generic lifetimes and at least one concrete ('static) lifetime. Some additional examples:

// Broken
async fn frobnicate(_a: &str, _b: &'static bool, _c: &i32) {}
async fn frobnicate(_a: &'static str, _b: &bool, _c: &i32) {}

// Not broken, only one generic lifetime
async fn frobnicate(_a: &str, _b: &'static bool) {}
async fn frobnicate(_a: &str, _b: &'static bool, _c: &'static i32) {}

// Not broken, no static lifetime
async fn frobnicate(_a: &str, _b: &bool, _c: &i32) {}

// Broken
async fn frobnicate(_a: &str, _b: &'static bool, _c: &'static i32, _d: &String) {}

• It doesn't appear to matter what order the lifetimes appear in, nor does it matter whether the lifetimes exist as part of a reference type (&'a T) or named type (Cow<'a, str>).
• It doesn't matter whether or not the lifetimes are named or elided

Meta

This bug is present on stable (1.62.0), beta (1.63.0-beta.5 2022-07-10 93ef0cd), and nightly (1.64.0-nightly 2022-07-11 38b7215).

Possibly related to #63033.

Diagnostics

Separate from the compiler bug here, there seems to be a related diagnostics bug, where the compiler describes some lifetime called '_#23r without pointing it out in the message.

[lqd]

note: if the 2 generic lifetimes are named and you relate them, then this will compile, because having one outlive the other will offer a "least choice" and be picked.

This looks to me to be #63033 indeed, and will be fixed by #89056. The tests there are virtually the same as the examples in the OP.

[Jules-Bertholet]

This was fixed in 1.69.

[fmease]

All snippets now compile successfully. Closing as fixed.