regression from error on elided lifetime in path in -> impl Trait<...>

[BoxyUwU]

Code

I tried this code:

use std::marker::PhantomData;

struct Foo<'a>(PhantomData<&'a ()>);

fn foo() -> impl Fn(Foo) {
    |_| ()
}

fn main() {}

I expected to see this happen: it compile

Instead, this happened: it didnt

error[E0106]: missing lifetime specifier
 --> src/main.rs:5:21
  |
5 | fn foo() -> impl Fn(Foo) {
  |                     ^^^ expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime
  |
5 | fn foo() -> impl Fn(Foo<'static>) {
  |                     ~~~~~~~~~~~~

For more information about this error, try `rustc --explain E0106`.

Version it worked on

It most recently worked on Rust 1.60 and this nighty:

rustc 1.62.0-nightly (69a5d2481 2022-04-27)
binary: rustc
commit-hash: 69a5d2481e856a5a18885390b8cf6950b9ff8dd3
commit-date: 2022-04-27
host: x86_64-unknown-linux-gnu
release: 1.62.0-nightly
LLVM version: 14.0.1

Version with regression

rustc --version --verbose:

rustc 1.62.0-nightly (e85edd9a8 2022-04-28)
binary: rustc
commit-hash: e85edd9a844b523a02dbd89f3c02cd13e4c9fe46
commit-date: 2022-04-28
host: x86_64-unknown-linux-gnu
release: 1.62.0-nightly
LLVM version: 14.0.1

cargo bisect

searched nightlies: from nightly-2022-04-26 to nightly-2022-04-29
regressed nightly: nightly-2022-04-29
searched commit range: 69a5d24...e85edd9
regressed commit: c95346b

bisected with cargo-bisect-rustc v0.6.3

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start=2022-04-26 

[inquisitivecrystal]

Slightly simplified reproduction:

struct Foo<'a>(&'a ());

fn foo() -> impl Fn(Foo) {
    |_| ()
}

fn main() {}

In other words, this isn't specific to PhantomData.

[inquisitivecrystal]

Since this has been fixed now and we never received any reports outside of bevy, I'm going to go ahead and retroactively mark this as P-high. I had suggested P-critical on the assumption that this would hit a lot more code, but that appears not to have been correct.