SimpleObject: error: lifetime may not live long enough #900

bbigras · 2022-04-20T23:46:04Z

I got some weird error after using #[graphql(complex)] and #[ComplexObject] on other struct.

So the affected struct doesn't have the "complex" thing.

I'm probably using nested ComplexObject that uses some dataloaders.

I'll try to make a minimal, reproducible example.

Expected Behavior

Actual Behavior

13 | #[derive(Debug, PartialEq, SimpleObject)]
   |                            -^^^^^^^^^^^
   |                            |
   |                            let's call the lifetime of this reference `'2`
   |                            let's call the lifetime of this reference `'1`
   |                            associated function was supposed to return data with lifetime `'1` but it is returning data with lifetime `'2`
   |                            in this derive macro expansion
   |
  ::: /home/bbigras/.cargo/registry/src/github.com-1ecc6299db9ec823/async-graphql-derive-3.0.38/src/lib.rs:47:1

Steps to Reproduce the Problem

Specifications

Version: 3.0.38
Platform: NixOS 22.05 (Quokka) x86_64
Subsystem:

The text was updated successfully, but these errors were encountered:

sunli829 · 2022-05-01T01:56:09Z

Please provide an example that reproduces this error.

kennetpostigo · 2022-05-01T16:52:33Z

I get the same thing locally since i've updated async-graphql, it happens sporadically

kennetpostigo · 2022-05-01T16:53:35Z

After a clean build it goes away but comes back after a while

bbigras · 2022-05-01T17:09:32Z

After a clean build it goes away but comes back after a while

I had something similar too.

sunli829 · 2022-05-02T03:28:09Z

Could you please provide an example that can reproduce this problem?😁

bbigras · 2022-05-02T03:49:50Z

Yes sorry. I'll be back home tomorrow. (I should have still made one earlier as promised when I opened the issue though)

bbigras · 2022-05-02T22:24:26Z

I think I'm able to reproduce. There's a compiler bug, but I'm not sure yet if both problems are related.

error: lifetime may not live long enough
  --> src/query.rs:53:26
   |
53 | #[derive(Clone, Default, SimpleObject)]
   |                          -^^^^^^^^^^^
   |                          |
   |                          let's call the lifetime of this reference `'1`
   |                          let's call the lifetime of this reference `'2`
   |                          associated function was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`
   |
   = note: this error originates in the derive macro `SimpleObject` (in Nightly builds, run with -Z macro-backtrace for more info)

error: internal compiler error: encountered incremental compilation error with mir_borrowck(async_graphql_900[a851]::query::{impl#16}::name)
  |
  = help: This is a known issue with the compiler. Run `cargo clean -p async_graphql_900` or `cargo clean` to allow your project to compile
  = note: Please follow the instructions below to create a bug report with the provided information
  = note: See <https://github.com/rust-lang/rust/issues/84970> for more information

bbigras · 2022-05-02T22:42:44Z

Now I can't reproduce it. I made a backup when it failed, but excluding my target folder.

So I never had the This is a known issue with the compiler. Run cargo clean -p async_graphql_900 or message before, but if I try cargo clean -p async_graphql_900 with my real project, the next build is fine.

Should we just assume that it's a bug with the compiler?

Here's my "minimal test case" https://github.com/bbigras/async-graphql-900 , but I can't reproduce the error at will.

EDIT: another weird thing is that I'm using the same compiler for my real project and the test case.

rbozan · 2022-05-09T18:13:13Z

Same on NixOS 22.05

al8n · 2022-05-23T02:20:40Z

I have met this, run cargo clean first, then this should work.

rbozan · 2022-05-23T06:19:09Z

I have a simple script now for this until there is some workaround as doing cargo clean just takes way too long for me. The issue happens quite often for me, when the compiler complains about other things beforehand for some reason this issue pops up even though the other issues have been fixed. If your workflow consists of cargo watch -x "run" and having an autosave in your editor just makes this issue very common.

cargo clean -p async-graphql -p *your crate name*

emwalker · 2022-06-01T02:52:35Z

I'm seeing this as well. I'm wondering whether it's a bug in Rust itself. Not sure exactly how to repro the issue, although I see it quite frequently.

vaikzs · 2022-06-05T04:22:56Z

cargo clean and cargo build works for me.

To reproduce --
I had async-graphql=3.0.38 and I upgraded to async-graphql=4.0.1 which immediately showed the error in my schema.

adzialocha · 2022-07-01T19:13:44Z

Can confirm that it is happening frequently with both async-graphql 3.0.38 and 4.0.1 on both Rust v1.61 and v1.62

vaikzs · 2022-07-02T00:46:32Z

@adzialocha It stopped happening. Not able to reproduce now either.

tbillington · 2022-07-03T06:08:58Z

Just started getting this, can't reliably trigger or reliably stop it from happening 😂 cargo clean temporarily fixes it as others said, perhaps something related to compilation order, or something not being recompiled?

async-graphql and async-graphql-axum 4.0.4 - stable-aarch64-apple-darwin

Bberky · 2022-07-03T20:20:20Z

I've been dealing with this for the past two days to no avail. cargo build -r works fine, but cargo check and cargo build (no release mode) fails. I've also been wondering whether it's got something to do with incremental compilation, but I'm really not sure, since I only get this when using the SimpleObject macro. I'm running the latest stable release of rustc and latest version of async-graphql.

emwalker · 2022-07-03T21:32:43Z

I was having this problem as well, and then it went away for good. Not sure what changed.

jwangnz · 2022-07-04T10:57:21Z

I am having this problem too, in Rust 1.62.0. But it works fine if I switch back to Rust 1.61.0.

danielhenrymantilla · 2022-07-04T13:24:13Z

Click to see how I reached that situation

Ok, I have investigated a bit the @Bberky's situation. They managed to reduce the issue to:

  #[derive(::async_graphql::SimpleObject)]
  pub struct A {
      field: String,
  }
  
+ pub struct B { field: String }

with a cargo c before and after that diff, on 1.62.0 , triggering a lifetime error message as reported by other people in this repo. By using an intermediary expansion trick, I got the expansion of SimpleObject on A to be:

Click to see the expansion

#[allow(clippy::all, clippy::pedantic)]
impl A {
    #[inline]
    #[allow(missing_docs)]
    async fn field(&self, ctx: &async_graphql::Context<'_>) -> async_graphql::Result<&String> {
        ::std::result::Result::Ok(&self.field)
    }
}
#[allow(clippy::all, clippy::pedantic)]
#[async_graphql::async_trait::async_trait]
impl async_graphql::resolver_utils::ContainerType for A {
    async fn resolve_field(
        &self,
        ctx: &async_graphql::Context<'_>,
    ) -> async_graphql::ServerResult<::std::option::Option<async_graphql::Value>> {
        if ctx.item.node.name.node == "field" {
            let f = async move {
                self.field(ctx)
                    .await
                    .map_err(|err| err.into_server_error(ctx.item.pos))
            };
            let obj = f.await.map_err(|err| ctx.set_error_path(err))?;
            let ctx_obj = ctx.with_selection_set(&ctx.item.node.selection_set);
            return async_graphql::OutputType::resolve(&obj, &ctx_obj, ctx.item)
                .await
                .map(::std::option::Option::Some);
        }
        ::std::result::Result::Ok(::std::option::Option::None)
    }
}
#[allow(clippy::all, clippy::pedantic)]
#[async_graphql::async_trait::async_trait]
impl async_graphql::OutputType for A {
    fn type_name() -> ::std::borrow::Cow<'static, ::std::primitive::str> {
        ::std::borrow::Cow::Borrowed("A")
    }
    fn create_type_info(registry: &mut async_graphql::registry::Registry) -> ::std::string::String {
        registry.create_output_type::<Self, _>(
            async_graphql::registry::MetaTypeId::Object,
            |registry| async_graphql::registry::MetaType::Object {
                name: ::std::borrow::Cow::into_owned(::std::borrow::Cow::Borrowed("A")),
                description: ::std::option::Option::None,
                fields: {
                    let mut fields = async_graphql::indexmap::IndexMap::new();
                    fields.insert(
                        ::std::borrow::ToOwned::to_owned("field"),
                        async_graphql::registry::MetaField {
                            name: ::std::borrow::ToOwned::to_owned("field"),
                            description: ::std::option::Option::None,
                            args: ::std::default::Default::default(),
                            ty: <String as async_graphql::OutputType>::create_type_info(registry),
                            deprecation: async_graphql::registry::Deprecation::NoDeprecated,
                            cache_control: async_graphql::CacheControl {
                                public: true,
                                max_age: 0usize,
                            },
                            external: false,
                            provides: ::std::option::Option::None,
                            requires: ::std::option::Option::None,
                            visible: ::std::option::Option::None,
                            compute_complexity: ::std::option::Option::None,
                        },
                    );
                    fields
                },
                cache_control: async_graphql::CacheControl {
                    public: true,
                    max_age: 0usize,
                },
                extends: false,
                keys: ::std::option::Option::None,
                visible: ::std::option::Option::None,
                is_subscription: false,
                rust_typename: ::std::any::type_name::<Self>(),
            },
        )
    }
    async fn resolve(
        &self,
        ctx: &async_graphql::ContextSelectionSet<'_>,
        _field: &async_graphql::Positioned<async_graphql::parser::types::Field>,
    ) -> async_graphql::ServerResult<async_graphql::Value> {
        async_graphql::resolver_utils::resolve_container(ctx, self).await
    }
}
impl async_graphql::ObjectType for A {}

From there, once that diff is applied in between cargo checks, I get:

error: lifetime may not live long enough
 --> /private/var/folders/m_/347zzk7j6nz08tt6z3tnd3z00000gn/T/tmp.qeHHjilha7/target/debug-proc-macros/test-f4020daedf6df8e8.rs:5:95
  |
5 |       async fn field(&self, ctx: &async_graphql::Context<'_>) -> async_graphql::Result<&String> {
  |  ____________________-___________________________________--_____________________________________^
  | |                    |                                   |
  | |                    |                                   let's call the lifetime of this reference `'2`
  | |                    let's call the lifetime of this reference `'1`
6 | |         ::std::result::Result::Ok(&self.field)
7 | |     }
  | |_____^ 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
 --> /private/var/folders/m_/347zzk7j6nz08tt6z3tnd3z00000gn/T/tmp.qeHHjilha7/target/debug-proc-macros/test-f4020daedf6df8e8.rs:6:9
  |
5 |     async fn field(&self, ctx: &async_graphql::Context<'_>) -> async_graphql::Result<&String> {
  |                    -                                   -- let's call the lifetime of this reference `'2`
  |                    |
  |                    let's call the lifetime of this reference `'1`
6 |         ::std::result::Result::Ok(&self.field)
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ associated function was supposed to return data with lifetime `'2` but it is returning data with lifetime `'1`

So the interesting part is that this does not involve async_trait whatsoever (I was afraid it would), and so the following part of the expansion is the one hitting the incremental compilation bug:

#[allow(clippy::all, clippy::pedantic)]
impl A {
    #[inline]
    #[allow(missing_docs)]
    async fn field(&self, ctx: &async_graphql::Context<'_>) -> async_graphql::Result<&String> {
        ::std::result::Result::Ok(&self.field)
    }
}

Finally, removing SimpleObject altogether from the equation, we end up with the following diff in between cargo checks running into the incremental compilation issue:

  pub struct A {
      field: String,
  }
  
  #[allow(clippy::all, clippy::pedantic)]
  impl A {
      #[inline]
      #[allow(missing_docs)]
      async fn field(&self, ctx: &async_graphql::Context<'_>) -> async_graphql::Result<&String> {
          ::std::result::Result::Ok(&self.field)
      }
  }
  
+ pub struct B { field: String, }

which ends up yielding the following stand-alone repro which I'll report to rust [EDIT: done]:

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();}

In the meantime, @sunli829 (or other maintainers of this crate), you may be able to dodge the compiler limitation by using https://docs.rs/fix-hidden-lifetime-bug on the non-async_trait-annotated async fns 🙂

danielhenrymantilla · 2022-07-04T14:01:57Z

Workaround

I've submitted #972 which implements the usage of fix_hidden_lifetime_bug as a palliative workaround for that compiler regression. To use it, follow the instructions described in that PR.

ControlCplusControlV · 2022-07-05T03:22:29Z

I was able to fix this issue by simple running export CARGO_INCREMENTAL=0, requires a better workstation to remain productive but it does work

danielhenrymantilla · 2022-07-05T17:15:03Z

@ControlCplusControlV you should be able to save in compile times by using that PR through a patch rather than fully disabling incremental altogether 🙂:

[patch.crates-io.async-graphql]
git = "https://github.com/danielhenrymantilla/async-graphql.git"
branch = "workaround-for-1-62-bug"

ivan · 2022-07-06T05:10:36Z

Here are some hopefully complete but overspecific repro steps:

rustup install nightly-2022-06-30 --force
rustup default nightly-2022-06-30
git clone https://github.com/bkonkle/rust-example-caster-api
cd rust-example-caster-api
cargo build

Edit ./libs/shows/src/episodes_service.rs:

diff --git a/libs/shows/src/episodes_service.rs b/libs/shows/src/episodes_service.rs
index a1b4c9f..e7dfddd 100644
--- a/libs/shows/src/episodes_service.rs
+++ b/libs/shows/src/episodes_service.rs
@@ -70,20 +70,7 @@ impl DefaultEpisodesService {
 #[async_trait]
 impl EpisodesService for DefaultEpisodesService {
     async fn get(&self, id: &str, with_show: &bool) -> Result<Option<Episode>> {
-        let query = episode_model::Entity::find_by_id(id.to_owned());
-
-        let episode = if *with_show {
-            query
-                .find_also_related(show_model::Entity)
-                .one(&*self.db)
-                .await?
-        } else {
-            query.one(&*self.db).await?.map(|u| (u, None))
-        };
-
-        let episode: EpisodeOption = episode.into();
-
-        Ok(episode.into())
+        Ok(None)
     }

     async fn get_by_ids(&self, ids: Vec<String>) -> Result<Vec<Episode>> {

cargo build # (assuming you didn't wrap cargo or turn off incremental builds)

and you'll see

error: lifetime may not live long enough
 --> libs/shows/src/show_model.rs:9:77
  |
9 |     Clone, Debug, Eq, PartialEq, DeriveEntityModel, Deserialize, Serialize, SimpleObject, PolarClass,
  |                                                                             -^^^^^^^^^^^
  |                                                                             |
  |                                                                             let's call the lifetime of this reference `'2`
  |                                                                             let's call the lifetime of this reference `'1`
  |                                                                             associated function was supposed to return data with lifetime `'1` but it is returning data with lifetime `'2`
  |
  = note: this error originates in the derive macro `SimpleObject` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider introducing a named lifetime parameter and update trait if needed
  |
9 ~     Clone, Debug, Eq, PartialEq, DeriveEntityModel, Deserialize, Serialize, 'a'aimpleObject, PolarClass,
10| )]
...
16|     #[polar(attribute)]
17~     pub id<'a>: String,
  |

If you rm -rf target, it will then build fine.

adzialocha · 2022-07-21T14:19:54Z

This is probably fixed now in Rust 1.62.1: rust-lang/rust#98890

ivan · 2022-07-23T18:29:02Z

I tested my #900 (comment) to confirm nightly-2022-07-23 (rustc 1.64.0-nightly (848090dcd 2022-07-22)) is fixed.

github-actions · 2022-08-27T02:15:30Z

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

github-actions · 2022-09-01T02:15:33Z

This issue was closed because it has been stalled for 5 days with no activity.

bbigras added the bug Something isn't working label Apr 20, 2022

bbigras mentioned this issue May 8, 2022

thread 'rustc' panicked at 'Found unstable fingerprints for mir_borrowck rust-lang/rust#96655

Closed

adzialocha mentioned this issue Jul 1, 2022

lifetime may not live long enough error in SimpleObject macro p2panda/aquadoggo#185

Closed

danielhenrymantilla mentioned this issue Jul 4, 2022

Incremental compilation bug with async fn method capturing multiple lifetimes rust-lang/rust#98890

Closed

danielhenrymantilla added a commit to danielhenrymantilla/async-graphql that referenced this issue Jul 4, 2022

Workaround for async-graphql#900

572ed3f

danielhenrymantilla added a commit to danielhenrymantilla/async-graphql that referenced this issue Jul 4, 2022

Workaround for async-graphql#900

6dae5c8

ivan mentioned this issue Jul 6, 2022

Palliative workaround for #900 #972

Closed

bbigras mentioned this issue Jul 12, 2022

Lifetime errors on SimpleObject #975

Closed

github-actions bot added the Stale label Aug 27, 2022

github-actions bot closed this as completed Sep 1, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SimpleObject: error: lifetime may not live long enough #900

SimpleObject: error: lifetime may not live long enough #900

bbigras commented Apr 20, 2022

sunli829 commented May 1, 2022

kennetpostigo commented May 1, 2022

kennetpostigo commented May 1, 2022

bbigras commented May 1, 2022

sunli829 commented May 2, 2022

bbigras commented May 2, 2022

bbigras commented May 2, 2022

bbigras commented May 2, 2022 •

edited

Loading

rbozan commented May 9, 2022

al8n commented May 23, 2022

rbozan commented May 23, 2022 •

edited

Loading

emwalker commented Jun 1, 2022 •

edited

Loading

vaikzs commented Jun 5, 2022

adzialocha commented Jul 1, 2022

vaikzs commented Jul 2, 2022

tbillington commented Jul 3, 2022 •

edited

Loading

Bberky commented Jul 3, 2022

emwalker commented Jul 3, 2022

jwangnz commented Jul 4, 2022

danielhenrymantilla commented Jul 4, 2022 •

edited

Loading

danielhenrymantilla commented Jul 4, 2022 •

edited

Loading

ControlCplusControlV commented Jul 5, 2022

danielhenrymantilla commented Jul 5, 2022 •

edited

Loading

ivan commented Jul 6, 2022

adzialocha commented Jul 21, 2022

ivan commented Jul 23, 2022

github-actions bot commented Aug 27, 2022

github-actions bot commented Sep 1, 2022

SimpleObject: error: lifetime may not live long enough #900

SimpleObject: error: lifetime may not live long enough #900

Comments

bbigras commented Apr 20, 2022

Expected Behavior

Actual Behavior

Steps to Reproduce the Problem

Specifications

sunli829 commented May 1, 2022

kennetpostigo commented May 1, 2022

kennetpostigo commented May 1, 2022

bbigras commented May 1, 2022

sunli829 commented May 2, 2022

bbigras commented May 2, 2022

bbigras commented May 2, 2022

bbigras commented May 2, 2022 • edited Loading

rbozan commented May 9, 2022

al8n commented May 23, 2022

rbozan commented May 23, 2022 • edited Loading

emwalker commented Jun 1, 2022 • edited Loading

vaikzs commented Jun 5, 2022

adzialocha commented Jul 1, 2022

vaikzs commented Jul 2, 2022

tbillington commented Jul 3, 2022 • edited Loading

Bberky commented Jul 3, 2022

emwalker commented Jul 3, 2022

jwangnz commented Jul 4, 2022

danielhenrymantilla commented Jul 4, 2022 • edited Loading

danielhenrymantilla commented Jul 4, 2022 • edited Loading

Workaround

ControlCplusControlV commented Jul 5, 2022

danielhenrymantilla commented Jul 5, 2022 • edited Loading

ivan commented Jul 6, 2022

adzialocha commented Jul 21, 2022

ivan commented Jul 23, 2022

github-actions bot commented Aug 27, 2022

github-actions bot commented Sep 1, 2022

bbigras commented May 2, 2022 •

edited

Loading

rbozan commented May 23, 2022 •

edited

Loading

emwalker commented Jun 1, 2022 •

edited

Loading

tbillington commented Jul 3, 2022 •

edited

Loading

danielhenrymantilla commented Jul 4, 2022 •

edited

Loading

danielhenrymantilla commented Jul 4, 2022 •

edited

Loading

danielhenrymantilla commented Jul 5, 2022 •

edited

Loading