Skip to content

Mixing async functions and &mut leads to overflow evaluating requirement #55809

Description

@agrif

Code:

#![feature(async_await, await_macro, futures_api)]

// Consider this a stand-in for tokio::io::AsyncRead
trait Foo { }
impl Foo for () { }
impl<'a, T> Foo for &'a mut T where T: Foo { }

// Consider this a stand-in for tokio::io::read
async fn foo_async<T>(_v: T) -> u8 where T: Foo {
    0
}

// this should just act exactly like foo_async...
async fn bad<T>(v: T) -> u8 where T: Foo {
    await!(foo_async(v))
}

// let's see if it is!
async fn async_main() {
    let mut v = ();
    
    // compiler error:
    let _ = await!(bad(&mut v));
    // totally fine:
    let _ = await!(foo_async(&mut v));
    // also totally fine:
    let _ = await!(bad(v));
}

fn main() {
    let _ = async_main();
}

Playground.

This fails to compile:

Compiling playground v0.0.1 (/playground)
error[E0275]: overflow evaluating the requirement `[static generator@src/main.rs:9:49: 11:2 {}]: std::marker::Freeze`
  |
  = help: consider adding a `#![recursion_limit="128"]` attribute to your crate
  = note: required because of the requirements on the impl of `std::marker::Freeze` for `[static generator@src/main.rs:9:49: 11:2 {}]`
[ ... line repeated many, many times ... ]
  = note: required because it appears within the type `impl std::future::Future`
  = note: required because it appears within the type `impl std::future::Future`
  = note: required because it appears within the type `{impl std::future::Future, ()}`
  = note: required because it appears within the type `[static generator@src/main.rs:14:42: 16:2 v:&mut () {impl std::future::Future, ()}]`
  = note: required because it appears within the type `std::future::GenFuture<[static generator@src/main.rs:14:42: 16:2 v:&mut () {impl std::future::Future, ()}]>`
  = note: required because it appears within the type `impl std::future::Future`
  = note: required because it appears within the type `impl std::future::Future`
  = note: required because it appears within the type `for<'r, 's> {(), impl std::future::Future, impl std::future::Future, impl std::future::Future}`
  = note: required because it appears within the type `[static generator@src/main.rs:19:23: 28:2 for<'r, 's> {(), impl std::future::Future, impl std::future::Future, impl std::future::Future}]`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0275`.
error: Could not compile `playground`.

This might be related to #50674, except that the code that triggers it seems more likely to be valid. I ran into this bug when trying to use tokio to read data and pass it off to serde. At the very least, the error message is extremely confusing.

Slightly modifying this code will occasionally trigger another compiler error (something about DeBruijn indices) but I have lost the exact code that triggers it.

Activity

  1. paracat commented on Nov 25, 2018

    @paracat

    i have produced the same error in a project:

    https://github.com/paracat/reflow/commit/d25aa1f4364c70f512d58cb6946d56faece5b5d8

    though i haven't extracted a minimal snippet, the cause of the problem is in the latest commit that only changes several lines

    i have also found the code that produces the DeBruijn error. It's the commit before this one. It seems whether ? is used for error handling matters

    apart from the two last commits that produce these two different errors, previous commits compile fine

    i believe this is related to #53989

  2. nikomatsakis commented on Feb 22, 2019

    @nikomatsakis
    Contributor

    Maybe related to #55809 ?

  3. eminence commented on Feb 23, 2019

    @eminence
    Contributor

    @nikomatsakis that link is just back to this same issue. What issue did you actually mean to link?

  4. nikomatsakis commented on Mar 5, 2019

    @nikomatsakis
    Contributor

    @eminence good point, I don't remember anymore =)

  5. nikomatsakis commented on Mar 5, 2019

    @nikomatsakis
    Contributor

    Marking as blocking -- we should be trying to figure out what is happening here, at least, and deciding whether to block on it.

  6. self-assigned this
    on Mar 5, 2019
  7. nikomatsakis commented on Mar 5, 2019

    @nikomatsakis
    Contributor

    Assigning to myself to try and do some investigation.

  8. removed their assignment
    on Mar 5, 2019
  9. self-assigned this
    on Mar 12, 2019
  10. added a commit that references this issue on Mar 13, 2019
  11. davidtwco commented on Mar 13, 2019

    @davidtwco
    Member

    This code compiles successfully when I check locally against nightly and a build of master, I've submitted #59156 with a regression test.

  12. added
    E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.
    on Mar 13, 2019
  13. added a commit that references this issue on Mar 13, 2019
  14. added a commit that references this issue on Mar 14, 2019
  15. added a commit that references this issue on Mar 15, 2019
  16. added a commit that references this issue on Mar 16, 2019
  17. added a commit that references this issue on Mar 16, 2019
  18. added a commit that references this issue on Mar 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-async-awaitArea: Async & AwaitA-coroutinesArea: CoroutinesAsyncAwait-PolishAsync-await issues that are part of the "polish" areaE-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions