Random `lifetime may not live long enough` from other part of the code

[DzenanJupic]

I just stumbled across a weird and inconsistent behaviour, that seems unreasonable to me.

The project I'm working on is a big company project (closed source) with quite some files. While fixing a bug and editing one line in one module (src/dispatcher/compiler/module_range.rs) the compiler suddenly decided to reject the code of a function from a completely different module (src/services/module_state_service.rs) that has absolutely nothing to do with the module I'm working on.

The change that I made:

fn get_next_module_start(&self, module: &FunctionalModule<'a>, starter: &'a Fmid) -> Result<usize> {
        // -- snip --
        WorkflowIterator::exe_path_iter(
            self.modules,
            starter,
            |m| m.fmd.next_module.as_ref().into_option(),
-           |m| super::sort_exe_paths(&m.fmd.exe_paths),
+           |m| (m != module).then(|| super::sort_exe_paths(&m.fmd.exe_paths)).into_iter().flatten(),
            |m| m.md.kind,
        )
        // -- snip --
}

The compiler error:

error: lifetime may not live long enough
  --> src/services/module_state_service.rs:35:44
   |
32 |           &'_ self,
   |            -- let's call the lifetime of this reference `'1`
33 |           workflow_id: &WorkflowGroupId,
34 |           fmid: &Fmid,
   |                 - let's call the lifetime of this reference `'2`
35 |       ) -> Option<RwLockReadGuard<'_, [u8]>> {
   |  ____________________________________________^
36 | |         let map_guard = self.module_state.read().await;
37 | |
38 | |         let contains_state = map_guard
...  |
49 | |         }))
50 | |     }
   | |_____^ associated function was supposed to return data with lifetime `'1` but it is returning data with lifetime `'2`

error: lifetime may not live long enough
  --> src/services/module_state_service.rs:47:9
   |
32 |           &'_ self,
   |            -- let's call the lifetime of this reference `'1`
33 |           workflow_id: &WorkflowGroupId,
34 |           fmid: &Fmid,
   |                 - let's call the lifetime of this reference `'2`
...
47 | /         Some(RwLockReadGuard::map(map_guard, |map| {
48 | |             &**map.get(workflow_id).unwrap().get(fmid).unwrap()
49 | |         }))
   | |___________^ associated function was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`

The function the compiler complains about:

pub async fn get_module_state(
    &'_ self,
    workflow_id: &WorkflowGroupId,
    fmid: &Fmid,
) -> Option<RwLockReadGuard<'_, [u8]>> {
    let map_guard = self.module_state.read().await;

    let contains_state = map_guard
        .get(workflow_id)
        .map(|map| map.contains_key(fmid))
        .unwrap_or_default();

    if !contains_state {
        return None;
    }

    Some(RwLockReadGuard::map(map_guard, |map| {
        &**map.get(workflow_id).unwrap().get(fmid).unwrap()
    }))
}

When undoing the one-line change, the code compiled fine again, and after redoing it, it failed to compile again.
Now, after indenting a few pieces of code, to make pasting them into GitHub easier, the compiler again accepts the code.
I'm also no longer able to recreate the error.

I know, that's essentially nothing to work with, and I'm not even able to recreate the issue myself anymore, but it seems worth reporting to me.

[DzenanJupic]

Could be closed immediately if not of value.

[Edgeworth]

This has also been happening to me on recent nightlies (for the past week or two). Unfortunately, it does sound like a hard to repro bug. I have found this problem happens much more in rust-analyzer than in command line compiles, not sure if that means anything though.

As a workaround, I am doing a clean rebuild.

[Edgeworth]

This is now happening constantly for me (almost every build). Unfortunately, I don't have a repro. It does seem to be somehow related to rust-analyzer though (very low confidence for this).

[DzenanJupic]

I don't use rust-analyzer, so it's probably not the origin. Though I didn't have any more problems so far.

[Demindiro]

I also had this happen though I haven't been able to reproduce it either. As far as I can tell it's related to async functions since I haven't seen it occur in any other case. Specifying lifetime bounds manually seems to help though.

[audunska]

Seeing something similar in our closed-source module. The beta compiler (1.62.0-beta.4) suddenly started rejecting some sqlx code which looks like this (details omitted):

#[derive(Debug, sqlx::FromRow)]
struct Grid {
  id: i64,
  row: f32,
};

struct Target {
  id: i64,
  grid_id: Option<i64>,
  ...
}

/// Just for namespacing
struct GridSql;

impl GridSql {
    pub async fn add_empty<'t>(
        target: &Target,
        mut tx: sqlx::Transaction<'t, Postgres>,
    ) -> sqlx::Result<sqlx::Transaction<'t, Postgres>> {
        let grid_id = sqlx::query_as!(
            Grid,
            r#"
            INSERT INTO grid (
               row
            ) VALUES($1)
            RETURNING
                id, ...
            "#,
            0.0,
        )
        .fetch_one(&mut tx)
        .await?
        .id;
        sqlx::query!(
            "UPDATE target SET grid_id = $1 WHERE id = $2",
            grid_id,
            target.id,
        )
        .execute(&mut tx)
        .await?;
        Ok(tx)
    }
}

The error message is:

error: lifetime may not live long enough
  --> src/lib/grid.rs:70:56
   |
67 |       pub async fn add_empty<'t>(
   |                              -- lifetime `'t` defined here
68 |           target: &Target,
   |                         - let's call the lifetime of this reference `'1`
69 |           mut tx: sqlx::Transaction<'t, Postgres>,
70 |       ) -> sqlx::Result<sqlx::Transaction<'t, Postgres>> {
   |  ________________________________________________________^
71 | |         let grid_id = sqlx::query_as!(
72 | |             Grid,
73 | |             r#"
...  |
97 | |         Ok(tx)
98 | |     }
   | |_____^ associated function was supposed to return data with lifetime `'t` but it is returning data with lifetime `'1`

error: lifetime may not live long enough
  --> src/lib/grid.rs:97:9
   |
67 |     pub async fn add_empty<'t>(
   |                            -- lifetime `'t` defined here
68 |         target: &Target,
   |                       - let's call the lifetime of this reference `'1`
...
97 |         Ok(tx)
   |         ^^^^^^ associated function was supposed to return data with lifetime `'1` but it is returning data with lifetime `'t`

This does not happen on stable.

Unfortunately, pulling the code out of the codebase verbatim did not give an error, so creating a reproducible example seems very hard again.

[DzenanJupic]

Hopefully, it has nothing to do with switching to the MIR borrow checker 😬. As far as I know, the plan is to stabilise it in August. Since @Edgeworth and I first noticed the bug on nightly, and it now propagated to beta this might be the case.

I have no idea when the NLL borrow checking was merged though, so it might be something different.

[DzenanJupic]

@rustbot label +A-NLL +NLL-complete

[Edgeworth]

By the way, I just found a breaking case for this even in the explicitly specified lifetimes case.

Originally, I had this, which sometimes produced the error message in the original post.
pub async fn rs(&mut self, key: &RecKey) -> Result<&RecSeries>

The frequency of this error decreased after I changed it to this signature:

pub async fn rs<'a, 'b>(&'a mut self, key: &'b RecKey) -> Result<&'a RecSeries>

However, I just got this error recently:

lifetime may not live long enough
consider adding the following bound: `'b: 'a`

Note that there is no reason for 'b to have to outlive 'a in my actual code (and indeed, it almost always compiles without issue).

[DzenanJupic]

Looks like one of the new error messages of the NLL borrow checker: https://jackh726.github.io/rust/2022/06/10/nll-stabilization.html