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

[michaelwoerister]

Let's keep this open until the backporting situation of the fix is clarified.

[cuviper]

#98959 was backported to 1.63.0-beta in #99098 -- ready to close?

[iliana]

Is this worth a stable backport? The experience of developing async code with this issue isn’t great.

[cuviper]

I tried a stable backport locally just to see, but it's non-trivial -- #98959 builds on changes from #97415 and #97023 at least, but that's as far as I investigated before giving up. Maybe a more targeted fix for 1.62.0 could be developed though.

[cjgillot]

Backported to stable.