Incremental compilation bug with `async fn` method capturing multiple lifetimes

[danielhenrymantilla]

Regression since 1.62.0

The following diff:

  struct Foo;

  impl Foo {
      async fn f(&self, _: &&()) -> &() {
          &()
      }
  }

+ enum Bar {}

if done in between cargo checks, makes the second check fail with:

error: lifetime may not live long enough
 --> src/lib.rs:5:43
  |
5 |           async fn f(&self, _: &&()) -> &() {
  |  ____________________-__________-___________^
  | |                    |          |
  | |                    |          let's call the lifetime of this reference `'2`
  | |                    let's call the lifetime of this reference `'1`
6 | |             &()
7 | |         }
  | |_________^ associated function was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`

• Aside: that error is printed twice, which is also curious.

To reproduce, the following snippet fails on the Playground:

fn main(){let _=std::process::Command::new("/bin/bash").args(&["-c", concat!(r##"{
set -euo pipefail
cd $(mktemp -d)


cargo init -q --name example --lib

cat> src/lib.rs <<'EOF'
    #![allow(unused)]
    struct Foo;
    
    impl Foo {
        async fn f(&self, _: &&()) -> &() {
            &()
        }
    }
EOF

(set -x
    cargo c -q
    { set +x; echo 'enum Bar {}'; } 2>/dev/null | tee -a src/lib.rs
    cargo c -q
)


echo ✅
} 2>&1"##)]).status();}

• Playground

I've reported it over #96655 to avoid defining a duplicate issue, but now that I've noticed it's a regression, I prefer to risk it being a dup than it going unnoticed.

I've also mentioned this over: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/incremental.20bug.20with.20async.20fns.20and.20lifetimes

---

Context

This is causing major breakage with users of async-graphql who have switched to Rust 1.62.0 or up, as showcased by:

• SimpleObject: error: lifetime may not live long enough async-graphql/async-graphql#900

• https://discord.com/channels/273534239310479360/993456385448751124/993456385448751124

---

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[michaelwoerister]

The bug also reproduces when the enum Bar {} is added above the impl, but only when that does not change the spans of the impl. It also reproduces when the enum Bar {} is add in a different file, or when a struct or an fn is added instead.

This suggests to me that this is somehow related to the overall set of DefIds changing.

It does not reproduce when the function is non-async.

@rust-lang/wg-incr-comp, any ideas? Where there any big refactorings during that time frame that could be the cause of this?

[michaelwoerister]

Maybe something related to generators / async functions generates numeric IDs based raw DefIndex values which are then not hashed in a stable way?

[lqd]

Bisection seems to point to #91557

[michaelwoerister]

That does sound related. @cjgillot might have an idea.

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical