Using the format!() macro with an async function makes the whole Future non-Send

[Hocuri]

I tried this code: (minimal reproducible example; for the actual code see deltachat/deltachat-core-rust#3591)

use core::future::Future;
use core::pin::Pin;

fn build_string() -> Pin<Box<dyn Future<Output = String> + Send>> {
    Box::pin(async move {
        let mut string_builder = "<h>".to_string();
        string_builder += &format!("Hello {}", helper().await);
        string_builder += "</h>";
        string_builder
    })
}

async fn helper() -> String {
    "World".to_string()
}

Playground

Note that we are using,

format!("Hello {}", helper().await)

in a context where the Future needs to be Send; only this line without the string_builder seems not to be able to reproduce the issue though.

I expected to see this happen: That the code behaves the same as

let s = helper().await;
format!("Hello {}", s)

Instead, this happened:

There are two error messages (about line 5 and line 7); this issue is about the first one:

error: future cannot be sent between threads safely
 --> src/lib.rs:5:5
  |
5 |     Box::pin(async move {
  |     ^^^^^^^^^^^^^^^^^^^ future created by async block is not `Send`
  |
  = help: the trait `Sync` is not implemented for `core::fmt::Opaque`
note: future is not `Send` as this value is used across an await
 --> src/lib.rs:7:56
  |
7 |         string_builder += &format!("Hello {}", helper().await);
  |                            ----------------------------^^^^^^-
  |                            |                   |       |
  |                            |                   |       await occurs here, with `helper().await` maybe used later
  |                            |                   has type `ArgumentV1<'_>` which is not `Send`
  |                            `helper().await` is later dropped here
  = note: required for the cast to the object type `dyn Future<Output = String> + Send`

The second error message didn't appear in the original issue in deltachat/deltachat-core-rust#3591, possibly because there the call to Box::pin() and the format!() call are in two different crates:

error: generator cannot be sent between threads safely
  --> deltachat-jsonrpc/src/api/mod.rs:74:1
   |
74 | #[rpc(all_positional, ts_outdir = "typescript/generated")]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ future created by async block is not `Send`
   |
   = help: the trait `Sync` is not implemented for `core::fmt::Opaque`
   = note: required for the cast to the object type `dyn Future<Output = Result<Value, yerpc::Error>> + Send`
   = note: this error originates in the attribute macro `rpc` (in Nightly builds, run with -Z macro-backtrace for more info)

Meta

rustc --version --verbose

Probably doesn't matter, anyway:

rustc 1.61.0 (fe5b13d68 2022-05-18)
binary: rustc
commit-hash: fe5b13d681f25ee6474be29d748c65adcd91f69e
commit-date: 2022-05-18
host: x86_64-unknown-linux-gnu
release: 1.61.0
LLVM version: 14.0.0

@rustbot label +A-fmt

[Hocuri]

Notes:

• Maybe this can be fixed with Tracking issue for improving std::fmt::Arguments and format_args!() #99012 cc @m-ou-se
• See Better error messages for sending format! uses across thread boundaries. #82696, an issue about improving the error message.

I'll guess this is
@rustbot label +T-libs

[bjorn3]

Maybe this can be fixed with #99012

Maybe, maybe not. At the very least I think we should prevent this from accidentally starting to work as that would prevent ever returning to the old code even if the new code is found to have severe issues.

[m-ou-se]

This isn't a "bug", in the sense that this behaviour is as expected. However, that doesn't mean that we shouldn't consider changing the behaviour.

The problem is that format!("{}{}", a, b) currently erases the types of a and b, but we don't want to accidentally keep the non-Send a around if b is an .await expression. So the type-erased argument (ArgumentV1) is simply never Send, since it's not generic over the type it wraps.

#99012 could indeed fix it, but as @bjorn3 mentions, we should be careful not to accidentally make something new work without first considering whether we want to commit to the new behaviour.