SimpleObject: error: lifetime may not live long enough

[bbigras]

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/jiasu.xzqcsaa.nyc.mn-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:

[sunli829]

Please provide an example that reproduces this error.

[kennetpostigo]

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

[kennetpostigo]

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

[bbigras]

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

I had something similar too.

[sunli829]

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

[bbigras]

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

[bbigras]

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]

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]

Same on NixOS 22.05

[al8n]

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

[rbozan]

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]

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]

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.