rust-lang / rust-lang/rust

"one type is more general than the other" and "implementation of `FnOnce` is not general enough" errors for `!Send` future

Open
#145,094 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-diagnostics T-compiler
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

Code
// v7.6.3
use futures_concurrency::prelude::*;

async fn f() {
    async fn map_f(msg: &str) -> String {
        format!("hello {msg}")
    }

    let v: Vec<_> = vec!["chashu", "nori"]
        .into_co_stream()
        .map(|msg| map_f(msg))
        .collect()
        .await;
    println!("{v:?}");
}

const fn assert_send_future<T: Future + Send>(_: &T) {}

fn main() {
    assert_send_future(&f());
}
Current output
error[E0308]: mismatched types
  --> src/main.rs:19:5
   |
19 |     assert_send_future(&f());
   |     ^^^^^^^^^^^^^^^^^^^^^^^^ one type is more general than the other
   |
   = note: expected reference `&_`
              found reference `&_`
note: the lifetime requirement is introduced here
  --> src/main.rs:16:41
   |
16 | const fn assert_send_future<T: Future + Send>(_: &T) {}
   |                                         ^^^^

error[E0308]: mismatched types
  --> src/main.rs:19:5
   |
19 |     assert_send_future(&f());
   |     ^^^^^^^^^^^^^^^^^^^^^^^^ one type is more general than the other
   |
   = note: expected struct `std::future::Ready<&_>`
              found struct `std::future::Ready<&_>`
note: the lifetime requirement is introduced here
  --> src/main.rs:16:41
   |
16 | const fn assert_send_future<T: Future + Send>(_: &T) {}
   |                                         ^^^^

error: implementation of `FnOnce` is not general enough
  --> src/main.rs:19:5
   |
19 |     assert_send_future(&f());
   |     ^^^^^^^^^^^^^^^^^^^^^^^^ implementation of `FnOnce` is not general enough
   |
   = note: closure with signature `fn(&'0 str) -> impl Future<Output = String>` must implement `FnOnce<(&'1 str,)>`, for any two lifetimes `'0` and `'1`...
   = note: ...but it actually implements `FnOnce<(&str,)>`

error[E0308]: mismatched types
  --> src/main.rs:19:5
   |
19 |     assert_send_future(&f());
   |     ^^^^^^^^^^^^^^^^^^^^^^^^ one type is more general than the other
   |
   = note: expected opaque type `impl Future<Output = String>`
              found opaque type `impl Future<Output = String>`
   = note: distinct uses of `impl Trait` result in different opaque types
note: the lifetime requirement is introduced here
  --> src/main.rs:16:41
   |
16 | const fn assert_send_future<T: Future + Send>(_: &T) {}
   |                                         ^^^^

For more information about this error, try `rustc --explain E0308`.
error: could not compile `test-futures-concurrency` (bin "test-futures-concurrency") due to 4 previous errors
Desired output
future returned by `f` is not `Send`
Rationale and extra context

Should probably be part of https://github.com/rust-lang/rust/issues/110338

Other cases

Rust Version
$ rustc --version --verbose
rustc 1.89.0 (29483883e 2025-08-04)
binary: rustc
commit-hash: 29483883eed69d5fb4db01964cdf2af4d86e9cb2
commit-date: 2025-08-04
host: x86_64-unknown-linux-gnu
release: 1.89.0
LLVM version: 20.1.7
Anything else?

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the reproducer in src/main.rs using rustc 1.89.0, and compare the current diagnostics with the desired future returned by f is not Send output. Read rust-lang/rust#110338 for related context. Done means the reported !Send future case produces the clearer diagnostic without regressing the existing error behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
compilers
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.