Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nightly compiler bug: "lifetime mismatch" #94004

Closed
annmarie-switzer opened this issue Feb 14, 2022 · 10 comments · Fixed by #94088
Closed

Nightly compiler bug: "lifetime mismatch" #94004

annmarie-switzer opened this issue Feb 14, 2022 · 10 comments · Fixed by #94088
Assignees
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.
Milestone

Comments

@annmarie-switzer
Copy link

annmarie-switzer commented Feb 14, 2022

Nightly 2022-02-13 seems to have introduced a bug. Code that compiles properly on stable and nightly-2022-02-09 does not compile with nightly-2022-02-13:

$ cargo +nightly run run
   Compiling detect_core v0.0.0 (C:\git\datadetect\core)
error[E0308]: mismatched types
   --> core\src\analysis.rs:217:17
    |
217 |                   tokio::spawn(async move {
    |                   ^^^^^^^^^^^^ lifetime mismatch       
...
395 |       reqs.then(|req| async move {
    |  ________________________________-
396 | |         let data = serde_json::to_vec(&req).unwrap();
397 | |         let subj = format!("HASH_REQ.{}", &req.connector);
398 | |
...   |
447 | |         vec![header, doc]
448 | |     })
    | |     -
    | |     |
    | |_____the expected `async` block
    |       the found `async` block
    |
   ::: core\src\reporting\scan.rs:18:59
    |
18  |   pub async fn send_report(task_type: &str, stat: ScanStat) {
    |                                                             -
    |                                                             |
    |                                                             one of the expected opaque types
    |                                                             one of the found opaque types
    |
   ::: C:\Users\aswitzer\.cargo\registry\src\github.com-1ecc6299db9ec823\nats-0.16.0\src\asynk.rs:158:74
    |
158 |       pub async fn request(&self, subject: &str, msg: impl AsRef<[u8]>) -> io::Result<Message> {
    |                                                                            -------------------
    |                                                                            |
    |                                                                            one of the expected opaque types
    |                                                                            one of the found opaque types
    |
   ::: C:\Users\aswitzer\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib/rustlib/src/rust\library\core\src\future\mod.rs:65:43
    |
65  |   pub const fn from_generator<T>(gen: T) -> impl Future<Output = T::Return>
    |                                             -------------------------------
    |                                             |
    |                                             one of the expected opaque types
    |                                             one of the found opaque types
    |
note: while checking the return type of the `async fn`
   --> core\src\lib.rs:101:24
    |
101 | pub async fn nats() -> &'static nats::asynk::Connection {
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ checked the `Output` of this `async fn`, one of the expected opaque types
note: while checking the return type of the `async fn`
    |
101 | pub async fn nats() -> &'static nats::asynk::Connection {
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ checked the `Output` of this `async fn`, one of the found opaque types
    = note: expected opaque type `impl futures::Future<Output = [async output]>`
               found opaque type `impl futures::Future<Output = [async output]>`
note: the lifetime requirement is introduced here
   --> C:\Users\aswitzer\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-1.15.0\src\task\spawn.rs:127:21
    |
127 |         T: Future + Send + 'static,
    |                     ^^^^

For more information about this error, try `rustc --explain E0308`.
error: could not compile `detect_core` due to previous error
@annmarie-switzer annmarie-switzer added the C-bug Category: This is a bug. label Feb 14, 2022
@ehuss
Copy link
Contributor

ehuss commented Feb 15, 2022

Thanks for the report! Is this a public project you can share? Or perhaps you can put together a minimum reproduction? And perhaps you can narrow down to one specific nightly where it starts happening?

@andrewbanchich
Copy link
Contributor

Seems like this may be related to this PR which was part of Tokio 1.16, although I'm not sure why it the same code would compile on stable and not nightly.

@annmarie-switzer
Copy link
Author

@ehuss It is broken on nightly-2022-02-13 and nightly-2022-02-15, but works on nightly-2022-02-09. I can not share the repo but I will try to put together reproduction soon.

@Mark-Simulacrum Mark-Simulacrum added the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label Feb 16, 2022
@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Feb 16, 2022
@Mark-Simulacrum Mark-Simulacrum added this to the 1.60.0 milestone Feb 16, 2022
@annmarie-switzer
Copy link
Author

Sorry I misunderstood. We tested on nightly 2022-02-12 and it compiles. So something broke on the release on the 13th.

@annmarie-switzer
Copy link
Author

Sorry again - I thought I was on nightly-2022-02-13 when in reality I was not. It actually appears to be the release on the 14th that broke things.

9th - works
10th - works
11th - works
12th - works
13th - works
14th - BROKEN
15th - BROKEN
16th - BROKEN

@ehuss
Copy link
Contributor

ehuss commented Feb 16, 2022

I think it is likely caused by #91403, cc @cjgillot

@oli-obk
Copy link
Contributor

oli-obk commented Feb 16, 2022

Considering this regression and the perf regression, we should probably revert and try again in a new PR

@apiraino
Copy link
Contributor

Assigning priority as discussed in the Zulip thread of the Prioritization Working Group.

@rustbot label -I-prioritize +P-high

@rustbot rustbot added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Feb 17, 2022
@pnkfelix
Copy link
Member

@rustbot assign @cjgillot

to own reverting PR #91403 and ensuring that the revert is part of the soon-to-be-cut beta.

@pnkfelix pnkfelix self-assigned this Feb 17, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Feb 17, 2022
@Dirbaio
Copy link
Contributor

Dirbaio commented Feb 17, 2022

I have a standalone repro of something that builds on nightly-2022-02-13, fails on nightly-2022-02-14 as well. I'm not sure if it's the same bug. playground

use core::future::Future;

trait Callback<'a> {}

impl<'a, T, Fut> Callback<'a> for T
where
    T: FnOnce(&'a mut ()) -> Fut,
    Fut: Future<Output = ()> + 'a,
{
}

async fn transaction<Cb>(f: Cb)
where
    Cb: for<'a> Callback<'a>,
{
}

async fn my_callback(bus: &mut ()) {}

async fn boom() {
    transaction(my_callback).await;
}
error: implementation of `Callback` is not general enough
  [--> src/lib.rs:21:5
](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021#)   |
21 |     transaction(my_callback).await;
   |     ^^^^^^^^^^^ implementation of `Callback` is not general enough
   |
   = note: `fn(&mut ()) -> impl Future<Output = ()> {my_callback::<'_>}` must implement `Callback<'0>`, for any lifetime `'0`...
   = note: ...but it actually implements `Callback<'1>`, for some specific lifetime `'1`

@bors bors closed this as completed in feac2ec Feb 18, 2022
flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. P-high High priority regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants